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In this Issue 



Drafting plotter technology occupies a good many of our pages this month, with 
two design groups reporting on their new large-format drafting plotters — the 
HP DesignJet and the HP DraftMaster Plus. 

HP's thermal inkjet technology makes the DesignJet plotter as low-cost as a pen 
plotter and as fast as an electrostatic plotter. The pens, or print cartridges, are 
HP DeskJet printer cartridges, proved reliable by many years of DeskJet experi- 
ence. The plotter accepts either vector commands or raster commands, uses 
regular drafting plotter media, and automatically cuts and stacks roll media. The 
article on page 6 introduces the DesignJet and discusses the issues of print 
quality, media, media handling, and the user interface. The electronic and firmware design, including 
built-in vector-to-raster conversion and three custom integrated circuit chips, is the subject of the article 
on page 16. Because it wouldn't have been able to plot fast enough with one pen, the DesignJet uses 
two, and how it keeps the two pens properly aligned is explained in the article on page 24. The unusual 
chassis is a rugged, precise unit made up of low-cost nonprecision parts held rigidly in place by a clev- 
erly designed structure (page 28). In developing the mechanical architecture, the designers found that 
extra time invested in communication before beginning prototype design paid off in a shorter overall 
project and lower-than-expected costs, as they explain on page 32. 

The DraftMaster Plus drafting plotter is an enhanced version of the DraftMaster pen plotter. Improved 
plotting reliability, improved media handling, and an improved user interface all contribute to increased 
user productivity by reducing the need for operator intervention during plotting. The most common cus- 
tomer complaints about pen plotters concern reliability — pens running out of ink, drying out. or clogging. 
The SurePlot plotting system includes improved pens, extra pens, and a sensor system that detects de- 
fective lines and automatically replaces faulty pens so that 998 out of 1000 drawings meet user expecta- 
tions (page 35). Media handling is improved by roll feed and a new media cutter and tray (page 42). The 
enhanced user interface offers a redesigned front panel and simplified selection of pens, settings, and 
drawing quality (page 49). 

Hewlett-Packard's reduced instruction set computer architecture, called PA-RISC, provides for multi- 
processor implementations in which several processors share the work. Adding a processor board to a 
system turns out to be a very cost-effective way of improving the performance of a computer system, 
particularly for online transaction processing (OLTP). The operating system schedules the processors 
and keeps them from interfering with each other. The first multiprocessor implementation of the PA-RISC 
architecture supports up to four processors and is available in versions that run either the HP-UX* oper- 
ating system or the MPE/iX operating system. The article on page 56 tells how the HP-UX kernel was 
modified to support multiprocessor operation and shows how much the performance is improved by 
adding processors. A feature of multiprocessor HP-UX is that, unlike many multiprocessor operating 
systems, it can run on a uniprocessor system with no performance penalty. 

State-of-the-art very large-scale integrated circuits like microprocessors can contain millions of transistors 
and have hundreds of inputs and outputs. For various technical and logistical reasons, such chips are 
rarely mounted directly on printed circuit boards, but instead are supplied in packages, which are soldered 
onto the boards. While some packages provide high-performance electrical and thermal environments 
and some are easy to assemble and rework, the ideal package would meet all of these requirements. A 
packaging technology that comes closer to the ideal than any of its predecessors is described in the 
article on page 62. Based on an existing technology called tape automated bonding, or TAB, it maintains 
TAB's advantages of good performance and lower cost, but doesn't require TAB's expensive facilities and 
is easy to demount and rework. Called demountable TAB, or DTAB. it was developed by HP's Integrated 
Circuits Business Division. 
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As explained in our August 1992 issue, the HP 9000 Series 700 computer workstations have a built-in. or 
core, input/output system that provides a variety of industry-standard I/O ports Because many custom- 
ers will need higher performance or want to expand their systems, the Series 700 workstations also offer 
an I/O expansion bus, which accepts plug-in cards that provide additional industry-standard 1/0 ports. 
The EISA bus (EISA stands for Extended Industry Standard Architecture) was selected for the Series 700 
expansion bus because it is a high-performance bus that is expected to meet the needs of HP customers 
and because it meets HP's goal of converging to an industry-standard 1/0 bus for all new workstations. 
The article on page 78 describes the adapter that provides the EISA bus to the outside world, acting as a 
bridge to the internal Series 700 system bus. Four types of plug-in EISA I/O cards are now available for 
the Series 700: an IEEE 802.3 (Ethernet) LAN card, an IEEE 488 (HP-IB) card, a SCSI (Small Computer 
Systems Interface) card, and a programmable serial interface card. Discussed in the article on page 83, 
the cards use EISA bus master and DMA (direct memory access) methods to take advantage of the EISA 
burst-cycle protocol for high-speed data transfer The software for the EISA SCSI interface card is 
explained in the article on page 97, which also talks about recent extensions to the SCSI standard. 

The article on page 109 is from HP's Worldwide Support Systems (WSS) organization, where they develop 
mission-critical systems for HP's worldwide customer support business. Seeing the emergence of client/ 
server solutions based on open systems concepts, WSS began to migrate their applications to this new 
paradigm while it was still in its infancy and standards were still being defined. They developed a technical 
architecture that provides a framework for designing modern, integrated client/server applications. The 
article explains the architecture and relates WSS's experiences in migrating two existing applications. 

December is our annual index issue. The 1992 index starts on page 120. 

R.P. Dolan 
Editor 



Cover 

The pen carriage of the HP DesignJet large-format thermal inkjet drafting plotter is shown with a 
DesignJet plot. The two print cartridges (HP DeskJet printer type) can be seen, as can the lever or 
adjustable cam that is part of the mechanism for aligning the pens in the media direction (scan direction 
alignment is done by adjusting pen-firing timing). The red light-emitting diode (in the mirror) is part of the 
adjustment system— it illuminates a test line that's used to measure and correct pen misalignment. (The 
mirror isn't part of the pen carriage. We just put it there to show the LED. We also simulated the LED light 
for this photo.) 



What's Ahead 

The February issue will be entirely a lightwave technology issue, featuring articles on the design of the 
following fiber optic test instruments: 

• HP 8504A precision reflectometer 

• HP 8146A optical time-domain reflectometer 

• HP 83440 Series lightwave detectors 

. HP 8167A and 8168A tunable light sources 

• HP 81534A return loss module for the HP 8153A lightwave multimeter. 

Leading off the issue will be a paper summarizing the contributions of HP Laboratories' photonics 
research program to HP's lightwave product line. 



HP-UX is based un and is compatible with UNIX System Laboratories UNIX" operating system It alto complies with X/Open's" XPG3 POSIX 1003 I and 
SVID2 interface specifications 

UNIX is a legistered trademark ot UNIX System Laboratories Inc in Ihe USA. and other countries 
X/llpen is a trademark ot X/Open Company bmited in the UK and other countnes 
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A Large-Format Thermal Inkjet 
Drafting Plotter 



The HP DesignJet drafting plotter combines the low cost of pen plotters 
with the speed of electrostatic plotters. Throughput is almost independent 
of drawing complexity. The plotter uses the same roll and sheet media as 
pen plotters, and in roll mode, automatically cuts and stacks plots for 
unattended operation. 

by Robert A. Boeller, Samuel A. Stodder, John F. Meyer, and Victor T. Escobedo 



The major contribution of HP's Oral large-format drafting 
plotter, introduced in 1981, was high performance at a much 
lower price than had previously heen available. Through the 
application of HP's proprietary ink.jet technology, the new 
HP DesignJet large-format drafting plotter offers customers 
the same kind of cont rlbul ion in performance at low cost 
while providing greater reliability of the ink delivery system 
and greater user friendliness. 

The DesignJet plotter (Fig. 1 ) can plot a complex D-size 
drawing in three minutes on commonly available media. It is 




Fig. 1. The HI' DesignJet plotter uses thermal inkjel technology to 
produce large-format plots on commonly available drafting media. A 
roll-med mode allows unattended plotting with automatic cutting 
and stacking of completed plots. Resolution is 300 dots per inch and 
plot time for a I >-si/.e plot is about three minutes. 



quiet and pan produce several hundred plots without a pen 
change. It accepts single sheets or, lor unattended plotting, a 
roll of media. When a roll is used, a built-in cutter separates 
the plots into sheets, which fall into a media tray below the 
plotter. The plotter accepts vectors (HP-GI72 instructions) 
or raster data (HP Paster Transfer Language). Resolution is 
dpi* 

Low-cost plotting has been dominated by the traditional pen 
plotter. Pen plotter performance is usually characterized in 
terms of acceleration and velocity. The greater the complex- 
ity of the image, the longer it lakes lo plot. An architectural 
plot on E-size paper might be in the range of 100,000 to 
1.000,000 vectors. A typical throughput profile fora-lg, 
25-ips plotter might look as shown in Fig. 2. 

In contrast, the DesignJet plotter's performance does not 
Change much with drawing complexity. Throughput is more 
a function of the page size and the vector transmission and 
conversion time. The DesignJel plotter's built-in Intel S0960 
processor and electronic architecture make vector transmis- 
sion and conversion time very small. A typical throughput 
profile for the DesignJet plolter is shown in Fig. 3. 

HP inkjel technology also provides customers with an im- 
provement in writing system reliability. The inkjct pens each 
hold about :i8 cc of ink, and no priming is needed when 
stalling up. The EiesignJet plotter uses two pens, which will 
last for about 200 reasonably complex E-size plots. The plot- 
ter can be left unused for many weeks, and the writing sys- 
tem will always work without Intervention when it is needed. 

' A 600-dpi addressable resolution version known as the DesignJet BOO is now m production 
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Fig. 2. Pen plotter plot time as a function of plot complexity. 
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Fig. 3. Ill' DesignJet plotter pin lime as a Function of ploi 
complexity arid size. 

The DesignJet plotter represents a major contribution to- 
wards making a large plotter more friendly. Sheets and rolls 
load easily from the front of the machine and are ejected 
toward the front, making plot retrieval easy. The built-in 
cutter works well on all media types, including Mylar, which 
is usually a challenge because of its silica content. A passive 
media stacking system stacks up to 20 plots. 

The DesignJet ploiter is one of the Fust IIP products lo in- 
corporate a modular I/O slot thai will allow many IIP periph- 
erals to use the same I/O cards. At the product's introduc- 
tion, there were MIO (modular I/O) cards available that 
allow the DesignJet plotter to connect to some networks 
and to HP-IB (IEEE -188, EC 625) systems. The MIO strategy 
promises lo provide our customers with a much broader 
range of connectivity solutions as new cards are developed. 

Design Challenges 

We knew that print quality is our customers' most important 
need. But larger-format plotters require very tight tolerances 
over the large distances required to span an E-size sheet of 
paper. Unfortunately, the laws of physics dictate that large 
beams lose their stiffness rapidly as they gel longer. There- 
fore, we had lo engineer the product right from the beginning 
to be stiff enough and accurate enough to hold the required 
tolerances. 

To increase ihe plotting throughput, the DesignJet plotter 
incorporates two pens instead of just one. Two pens can 
print twice as fast as one, but must be aligned accurately, so 
that the customer does not see any banding or gaps at Ihe 
junction between pens. The same throughput requirement 
put demands on the vecior-io-rasler converter that trans- 
forms the IIP-GI/2 input into the raster dala thai the pen 
needs. 

We needed lo make a major improvement in the ease of us- 
ing and loading Ihe machine. Large-formal plots are difficult 



to handle, and our goal was to try to make the plotter as 
easy to use as an HP DeskJet printer. We also needed a way 
to stack plots as they came out of the machine. 

We needed to make the machine reliable so that it could be 
used unattended. This required careful design of the media 
path and the cutter system so thai paper would never jam or 
tear and the machine would lie guaranteed to work all ihe 
time without user intervention. 

We needed to be very cost conscious, and this required 
care in meeting design-for-assemblability and design-for- 
manufaeturability goals. It also created a need to integrate 
more of the electronics. 

We had a tremendous number of functions to implement in 
the firmware. Some of this functionality provides compati- 
bility with other HP plotters, such as front-panel control of 
line types and widths. Other functionality provides new op- 
portunities for using the plotter, such as our RTL ( Raster 
Transfer Language), which allows vectors and raster data to 
be mixed on the same plot, and our MIO support, which al- 
lows the plotter to be used on a network directly, without 
connecting through a server. 

Major Features 

The DesignJet pen carriage holds two print cartridges, along 
with a mechanism that allows one of the cartridges to move 
slightly relative to the other so that optimal print quality can 
be achieved. The carriage also holds optical sensore for auto- 
mating this adjustment and for automatically defecting the 
paper edges. 

The Y-axis drive servo system, which moves the carriage 
back and forth on precision rails, includes a linear encoder 
for maximum accuracy. The same V drive also progratumati- 
cally engages a separate cutter carriage that cuts roll-feed 
media. The media cutler consists of a carriage-mounted 
rotary blade that is spring-loaded against a fixed linear 
blade* 

A pen service station caps the inkjel cartridges lo prevent 
Ihe ink from drying oul when ihe plotter is not in use. The 
service station includes a wiper to help maintain a clean 
nozzle surface, which helps print quality. Also included is an 
ink-drop detector, which is used lo determine if the cartridge is 
firing properly. 

The X-axis drive servo system moves the media. The media 
drive system can handle a wide range of media widths up to 
:!(i inches, and is also capable of driving a wide range of me- 
dia types. A precisely dimensioned rubber roller provides a 
friction drive. 

The roll-feed assembly accepts rolls of media up lo 50 me- 
ters in length. A sheet stacking system collects the plots as 
they are Cut off the roll. 

System Block Diagram 

The DesignJet plotter block diagram, Fig. 4, shows Ihe rela- 
tionships of all of ihe major functional areas of the plotter. 

The culler design is similar, but not identical, to the media cutter ol the HP OaftMaster Plus 
plotter Isee article, paga 42) 
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Fig. 4. Simplified system hlor k diagram of the HI' DesignJet plotter. 



To Regulator 



The inpul/output pons are treated as memory addresses. 
The RS-232 universal asynchronous receiver/transmit ut 
(UART) is part of the processor support ASIC (application- 
specific integrated circuit). There are three ASICs in the 
Design.Iel plotter. 

1M bytes of system read-only memory (ROM) is used to 
store system firmware. 2M bytes of dynamic random-access 
memory ( DRAM) is standard. Expansion slols allow expan- 
sion of the DRAM lo 10M bytes. 2M bits or RAM is used to 
store swath informalion. An elecirically erasable read-only 
memory (EEROM) IC is used as nonvolaiile memory lo 
store variables thai must be retained when power is off. 

DRAM addressing is controlled by lite processor supporl 
ASIC. The main processor, an Intel 80966, communicates 
with the servo processor (an 8052) through the processor 
support ASIC, since the I wo processors run al different 
clock frequencies. 

The pen interface ASIC removes swath pixel data from the 
swalh RAM and transfers I he data lo the carriage ASIC, 
which is located on the pen carriage printed circuit assem- 
bly, through the trailing cable. The carriage ASIC creates the 
proper signals for the pen drivers. 

The processor supporl ASIC receives encoder feedback dala 
from the X-axis and Y-axis motors and outputs the data to 
the servo processor for calculation of the necessary pulse 
width modulation ( PWM ) signals to drive Ihe motors. The 
processor support ASIC outputs the PWM signals lo the mo- 
tor drivers, which are located on the interconnect printed 
circuit assembly. 

Front -panel and all sensor input (except ihe line sensor) 
goes to the servo processor, which also controls the fan. Ihe 
stepper motor thai moves the pen nozzle wiper blade, and 



the EEROM. A voltage regulator on the inlerconnect printed 
circuit assembly controls Ihe pen drive voltage. 

The pen carriage line sensor oulpul goes to an analog-to- 
digital converter (ADC), which outputs Ihe converted signal 
lo the carriage processor (an 8051 ). 

DesignJet Print Quality 

Good print quality is of prime importance for any prinler or 
plotter. An understanding of Ihe customers' prinl quality 
needs and how lo meel Ihem was critical to the success of 
Ihe Design.Iel plotter. 

During the investigation phase of Ihe DesignJet project both 
interna] and external surveys were conducted to determine 
how well a large-format, monochrome, I hernial Inkjet plot- 
ter would be perceived by Ihe target market. Pen plotter, 
electrostatic, and inkjel plots were shown to customers. 
Customer comments on prinl quality were recorded and 
categorized. Next, specific print quality attributes were iden- 
tified and special surveys were conducted to quantify what 
specifications had to be achieved to meet the customers' 
needs. These special surveys included media and print mode 
testing, bantling, vertical line straightness. and cockle testing. 

Media and Print Mode Testing 

The target market is primarily composed of pen plotter us- 
ers who need higher throughput. These users prefer to use 
the media types that are commonly available today for pen 
plotters. We found that most commonly available plotter 
bond papers exhibited excellent print quality when printing 
with one pass of ihe inkjet pen over the paper. However, 
when printing area fills on some vellums and translucent 
media, two passes of 50% ink density per pass were required 
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before customers would consider the samples to be final- 
quality plots (see Fig. 5). The two-pass print mode worked 
quite well to improve the uniformity of area fills. Commonly 
available polyester film media did not work well even wiih 
multiple passes. Therefore, a special film that is more recep- 
tive to the ink was developed to work with a two-pass print 
mode. 

Banding and Line Straightness 

To determine what were acceptable limits for banding, a 
survey was designed to test user sensitivity lo this print 
quality attribute. Plots were generated on a highly accurate 
drum printer. Adjacent swaths were printed with known 
displacements from Ihe ideal. This resulted in a range of 
plots, each with a different level of discrete swath boundary 
misalignment ( bands). When adjacent swaths are placed too 
far apart a light band or gap is visible and when adjacent 
swaths are placed loo close together a dark band or overlap 
appears. Users were asked to rank the plots for acceptabil- 
ity (see Fig. 6). By evaluating Ihe survey data we were able 
to determine how accurate the specifications for the print- 
ing mechanism would have to be in the paper axis direction. 

Line straightness was tested in much the same way. Plots 
were printed with discrete offsets at swath boundaries in 
the direction of swath scan. By evaluating the survey re- 
sults, we were able to determine how accurate the specifica- 
tions for the printing mechanism would have to be in the 
pen scan direction. 

Cockle Testing 

Cockle is the wrinkled appearance of paper after having 
being soaked in water and then left to dry. The high water 
content of the HP DeskJet pen ink results in significant 
cockle when applied in large area fills. Analysis of customer 
plots showed that most users do not plot with high print 
densities. However, solid area fills are used for small logos 
and thick lines. 

To belter understand user sensitivity to cockle, a lest was 
designed lo determine how dense a plot could be and still 
have acceptable cockle. Plots were printed with a pattern of 
evenly spaced square area fills. Area size and spacing were 
varied from plot to plot. Users were then asked lo rank the 
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Fig. 6. Plot acceptability as a fimrlion «f banding error. 

plots for cockle acceptability. The survey results showed us 
I hat for area fill sizes and spacing lhat would be typical for 
our target market, there would be no problem with cockle. 

Design Issues and Technical Risks 

After the primary print quality specifications were estab- 
lished based on user needs, the design effort commenced lo 
find ways to achieve these goals at the lowest possible cost. 
Key elements of the design were closely analyzed and risks 
were balanced. Worst -case analysis was done early to prove 
lhat various concepts could meet Ihe required error budgets. 
The areas in which it was most difficult to meet the required 
specifications were banding and line straightness. 

Handing error is the stun of errors caused by paper advance 
accuracy, pen-to-pen alignment in Ihe paper axis, and failed 
or weak pen nozzles. The banding tolerance specification is 
taken up mostly by pen-lo-pen alignment and paper advance 
errors. 

On the DesignJet plotter. Iwo DeskJet printer pens are used 
essentially as one larger pen to meet throughput goals. 
Worst -case analysis of Ihe pen carriage tolerances and Desk- 
Jet pen tolerances showed lhat this concept would result in 
banding because of pen misalignment in the paper axis, and 
lhat the banding would be much greater than the customer 
would tolerate. An automatic pen alignment system was 
designed to minimize the amounl of error budget consumed 
by pen alignment. 

The allowable error remaining for Ihe paper advance system 
resulted in a considerable design challenge. Several alterna- 
tive designs were analyzed using Monte Carlo simulation 
methods. The winning concept uses an indexing worm drive 
gear transmission scheme. This approach virtually elimi- 
nates cyclical errors caused by the motor, encoder, and 
worm pinion. To reduce the errors caused by variation of 
the effective diameter of the drive roller, a calibration is 
performed on the production line using Ihe DesignJet's ow n 
internal reference. 

Achieving the line straightness goal also proved lo be a diffi- 
cult task. The DesignJet ploltcrnoi only requires two Desk- 
Jet pens to ad as one larger pen bul also needs lo print bi- 
direclionally to achieve the throughput goals. Much attention 
had tO be given lo ihe alignment of the pens in Ihe scan 
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direction to achieve the vertical line straightness goal. A 
scheme was implemented by which pen alignment error in 
the scan direction and bidirectional error (carriage dead- 
hand) are measured with an optical sensor. These errors are 
then corrected by varying the timing ol' ink-drop firing. 

The difficulty arose when we tried to align pens that exhibit 
excessive spray along with the main ink drop. The effects of 
spray on alignment get worse as the pen-to-paper distance 
increases, but moving the pens close to the paper risked the 
possibility of a pen drag because of cockle in a high-tnk- 
density plot. The problem was minimized by doing a careful 
worst -case analysis of the pen-to-paper distance and moving 
the pen as close to the media as possible. Cockle amplitude 
was measured as a function of time lor paper and translu- 
cent bond to determine how close the pen could be to the 
paper without any possibility of touching (see Fig. 7). 

As mentioned above, cockle dictates how close the pen can 
be to the paper, which ultimately affects line quality. To 
minimize cockle, the paper path is designed to constrain the 
paper physically as much as possible. The paper is wrapped 
around a drive roller and is lensioned by an overdrive roller. 
In this way, paper cockle in the printing area is forced to a 
high-spat ial-frequency, low-amplitude state, allowing the pen 
to be located as close as possible to the paper. 

Production Control of Print Quality 

Meeting print quality goals is dependent not only on careful 
design but also on careful production control lo ensure that 
no product is shipped that does not meet all print quality 
specifications. On the DesignJet production line, several 
tests measure the performance of each machine for each 
print quality specification (see Fig. 8). 

The banding specification is checked by four tests. First, 
cyclical errors in the paper drive are automatically mea- 
sured and then analyzed with an FFT ( fast Fourier trans- 
form) algorithm. From this data, a faulty part in the drive 
train can be identified and replaced. Second, accurate paper 
movement is ensured by an absolute accuracy calibration 
test. Next, weak or faulty pen firing is checked by visual 
examination of a test plot. Lastly, print cartridge alignment 
in the paper direction is measured with the aid of a video 
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Fig. 7. Measurements of wet c oc kle (paper wrinkling after being wet 
and dried) as a function of time. 
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Fig. 8. Assembly line print quality attribute control for the HP 
DesignJet plotter, 

microscope measurement system. Vertical line straightness 
is also ensured by measuring a print sample with the video 
microscope system. 

Proper pen height above the paper is checked by two sepa- 
rate tests. First, slider rod straightness is measured as part 
of the chassis assembly procedure. Second, pen-to-paper 
distance is measured directly for each machine by installing 
a height gauge in the pen stall and measuring the distance to 
the platen at three different locations. 
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The final check for print quality is done by human inspection 
of a demonstration plot at the last station on the assembly 
line. 

DesignJet Media 

The media set plays an important part in the customer 
acceptability of a plotter. It was a requirement that the 
Hewlett-Packard media recommended for the new Design- 
Jet thermal irtkjet plotter provide consistent high quality, 
equal to or better than other brands on the market. The proj- 
ect goal was to use the current Hewlett-Packard pen plotter 
media set for the DesignJet plotter, the only exception being 
the drafting film. This goal presented a challenge in two 
areas: opaque bond paper and vellum. 

Opaque Bond Paper 

The then-current Hewlett-Packard bond was being changed 
concurrently with the development of the DesignJet plotter 
because of Hewlett-Packard environmental concerns and 
media archivability issues with the existing acid-process 
bond paper. A project had been initialed to develop a new 
alkaline plotter bond paper that would lie better for the envi- 
ronment, provide improved archivability, and have superior 
print quality. Adding the requirement to support a thermal 
inkjet plotter increased the complexity and risk of the proj- 
ect and necessitated meeting the more aggressive plotter 
development schedule. 

A major impetus for this alkaline paper project was the envi- 
ronmental issue. Alkaline paper processes use chemicals 
that are less harmful to the environment. Paper companies 
were changing their "plain papers" to alkaline partially in 
response to this concern. Plotter papers were not being con- 
sidered for t his change by the majority of plotter paper 
manufacturers, but we fell that Hewlett-Packard should be 
among the leaders in this effort. 

Pen plotter and thermal inkjet inks have water as a major 

component. In typical pen plotter inks, water makes up 
slightly more than half of the ink. Other cosolvents are pres- 
ent depending on I he type of pen and the manufacturer. In 
thermal inkjel ink. water makes up 9094 or more of the ink. 
The cosolvent, while a much smaller percentage of the total 
ink mixture, is much more aggressive. The challenge in devel- 
oping an alkaline paper that is compatible with both pen plot- 
ter ink and thermal inkjet ink involves the basic components 
of the paper sheet. 

The common plotter papers were and still are typically acid- 
process and were developed to meet the requirements of 
pen plotter inks. This means a moderately high level of inter- 
nal sizing compared to plain papers such as office paper or 
copy papers. Surface control of the image components of 
the ink is important to tnaintain fine line quality, Pen plotters 
emulate manual drafting methods, using pen strokes lo 
create the lines and Structures. Therefore, controlled re- 
moval of the solvents (water and others) from the surface of 
the sheet is not as critical as it is for the DesignJet thermal 
inkjel plotter, 

Alkaline papers use the same paper libers as acid paper and 
thfi process is very similar, using the same paper machine 



equipment. Alkaline papers differ from acid papers in two 
major areas: sizing and fillers. Sizing imparts water resis- 
tance along with other properties to the paper either 
through internal sizing or surface sizing. Fillers are used to 
fill spaces betw een the paper fibers, to improve printability. 
and to replace the more expensive paper fibers. The filler of 
choice for alkaline papers is calcium carbonate, and for acid 
papers the filler typically used is clay. 

Extensive testing of alkaline sizing agents indicated that 
their water resistivity is equal to or better than that of the 
acid sizing agents. Therefore, sizing did not appear to be the 
critical component. The next component of paper to evalu- 
ate was the calcium carbonate. Sample papers with varying 
amounts of calcium carbonate were evaluated with both pen 
plotter inks and thermal inkjet inks. The level of calcium 
carbonate in the paper sheet was inversely proportional to 
the print quality level of both pen plotter and thermal inkjet 
plotter output. Controlling the calcium carbonate level im- 
proved print quality but the improvement was not sufficient 
for Hewlett-Packard products, so sizing was revisited. 

The last component considered was the surface sizing. Our 
paper manufacturer had been working concurrently on pa- 
per components lo improve thermal inkjet performance on 
alkaline papers. The particular surface sizing component 
developed for other products was tested on our candidate 
paper, and resulted in improved control of the thermal inkjet 
ink on the surface of the paper. This provided the needed 
Improvement in print quality to make the paper acceptable. 

The final effort in developing the paper was to characterize 
the current media, understanding the requirements of pen 
plotters and thermal inkjet plotters, and then recreate the 
physical characteristics of the acid paper in the alkaline 
paper. Rigorous testing of the then-current acid paper was 
performed lo develop the model lo present to the paper 
manufacturer. Testing included all image and handling char- 
acteristics of the paper sheet. These included both media 
handling characteristics such as thickness, stiffness, surface 
smoothness, surface friction, tear strength, tensile strength, 
and moisture and image characteristics such as opacity, 
brightness, paper color, and porosity. 

The model was presented to the paper manufacturer along 
with a plotter test bed. As a result of I he early invesl igal ion 
and the investment in developing a detailed model of the 
sheet, the new alkaline opaque bond met all the print quality 
and schedule requirements for both pen plotters and lite 
new DesignJet plotter. Print quality for the DesignJet was 
optimized and critical performance parameters such as media 
handling, color response, and sheet feeding for pen plotters 
were maintained or improved. 

Vellum 

The vellum presented a different challenge. Development- 
phase testing of the DesignJet plotter with the vellum re- 
sulted in marginal performance because of the characteris- 
tics of the new improved thermal inkjel ink. Thus a new 
vellum was necessary to meet the prim quality goals. The 
DesignJet schedule required a successful vellum within six 
months. 

(continued on page 131 
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DesignJet Plotter User Interface Design: Learning the Hard Way about Human 
Interaction 



How many times have you picked up a product and found it easy to use' If a prod- 
uct is easy to use. it probably was no small task to make it that way With some 
products, even simple ones. I can be frustrated because I can't make it do what I 
expect it to do Either I don't know how or it doesn't have the capability The 
manual may be within reach but I have no interest in consulting it With any prod- 
uct, users hope to combine their own intuition with external clues to determine 
the machine's capabilities and correct operation What a confidence builder it is 
when a person can walk up to a new machine and operate it correctly' 

We engineers, with our generally analytical minds, think that the simple solution 
is to publish a manual with step-by-step instructions Although users expect such 
a manual, at least 50% will attempt operation without even opening it. Apparently 
users do not find it pleasant to build their mental model of a machine's operation 
by using only diagrams and text from written instructions. 

Although the cause is noble, achieving intuitive operation is not so easy A de- 
signer, familiar with each intricacy of the mechanism, will expiess an opinion and 
come up with the initial user interface design Is this going to work for all users 1 1 
think not, but it is a place to start 

Our brain is parallel processing input from five senses and filtering it through past 
experiences No amount of analytical thinking in a serial fashion can possibly 
predict the human response The designer's experience with the development 
precludes any useful help in the user interface area Perhaps, we might think, an 
experienced person could help us determine how people will react. Mistake' No 
one person can determine the best user interface that will appeal to the most 
people This is a very difficult concept When your manager tries out your design 
and has a certain difficulty, that can seem like the highest-priority problem, but it 
may just be a corner case User testing is the key 

The DesignJet plotter started life as a gleam in the eyes of an architectural team. 
Prototypes were built, and along with proving the functionality came early user 
testing of some of the concepts the designers were concerned about For example, 
to load roll media, the user needed to preselect roll format on the front panel, 
place the roll correctly on the spindle lit can go four waysl, insert the media into 
the load slot, and lift the pinch roller release lever to align Was the roll-to-spindle 
orientation intuitive? Would people lift the levet when instructed by the front panel? 

The designer's opinion was that we needed to redesign for automatic lever lift, we 
should not be asking people to raise the lever Mistake 1 No one person, especially 
the designer, can determine user reaction. A week's worth of investigation resulted 
in an unacceptable impact to cost and schedule and so the idea was reluctantly 
shelved. Later user testing showed that people had no problem or frustration when 
the display read "Lift lever." They simply lifted the only lever on the machine. 

The same initial user testing showed that all users intuitively oriented the roll on 
the spindle backwards This sent us into another redesign, this time for two 
months, resulting in a prototype that allowed the roll to be installed this way 
Mistake 1 Users look for clues and parallel process all information This new proto- 
type displayed a new set of problems of both function and ease of use Going back 
to the original design, a more subtle change was made. A graphic label installed 
under the roll cover was the clue that users were looking for. It was only in the 
absence of any other information that they showed the oppnsite preference for 
roll orientation 

With the initial concerns addressed by user testing, we thought we could continue 
with hard tooling Mistake! Not all user interface problem areas can be predicted 
The entire system must be tried by typical users not familiar with the product 



Testing after hard tooling revealed that people will not select sheet or roll mode 
before trying to load the media Initially a burton on the front panel toggled two 
light-emitting diodes that displayed the type of media the DesignJet plotter ex- 
pected From the previous problem, we had already learned that the DesignJet did 
not need to be redesigned, we simply had to provide more clues Now, after the 
load is initiated, the plotter pauses and asks the user, by means of the front-panel 
display, to select which format of media has been loaded. This tested well and has 
the added benefit of providing the user with time to stop and decide (with hands off) 
if the plotter has a good, even grip on the media before continuing Unfortunately in 
this case, the hard tooling needed to be modified as an unexpected expense. 

At the same time, it was found that first-time users almost always created a paper 
jam while trying to load This was, of course, unacceptable Observation of user 
tests showed the various techniques people were using to load. The DesignJet 
plotter grabs the media after a set amount of time when the media passes a 
sensor in the insertion slot. People did not know that they needed to wait for this 
time and then let go of the media so that it could move into the mechanism. We 
needed to provide some clues An audible click, which was part of the original 
concept, was not enough. Almost by accident, it was discovered that if we moved 
the media quickly at the start, users would instinctively let go 

Another problem was that some people were using a line on the side of the ma- 
chine to adjust the media squareness People complained that there needed to be 
a guide on the side to align the media It wasn't until we thought about the com 
ment that we realized this was how they expected to keep the media square. They 
were frustrated because the DesignJet would reject that load as misaligned It 
was not possible to use the marks on the side to adjust the squareness Our oilier 
plotters use a side surface to reference the media and these people were accus- 
tomed to that type of system The correct DesignJet method is to push the media 
against the pinch rollers which are, unfortunately, oul of sight The lines on the 
side were only an approximate left/right location reference Within 1/4 inch of the 
side line would have been fine. Our solution was to reduce the length of the line 
on the right so il didn't look like something to align to and to add a label in the 
area that explains in six different languages to "Push media against rear stops." A 
better solution might have been to make the pinch rollers visible to the user. 

The position selected for the label is not very eye-catching but has the benefit of 
not cluttering the appearance of the machine. While looking at this solution, Hie 
general comment was. "No one will ever see it " Mistake 1 Don't ask people to 
predict how others will perceive UsBr testing of first-time users showed that they 
were unsure of how to load and were actively searching for clues. Almost all 
noticed and comprehended the label A bail lift timing change bought us some 
extra design margin which, combined with the improved user interface, gave us a 
vastly improved and acceptable design. 

The design might be imptoved further now that we have gained a clearer under- 
standing of DesignJet user perceptions But to give an accurate model of user 
perception, user testing requires a complete product, and a complete product is 
not receptive to many changes This creates a minor dilemma neatly expressed as 
"In every product's development, there comes a time when you must shoot the 
engineer and go into production " In my case the wound was nol fatal and I'm 
recovering nicely. 

P Jeffrey Wield 
Design Engineer 

San Diego Technical Graphics Division 
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The manufacturing of a translucent 100% cotton velluni re- 
sults in internal and surface characteristics different from 
those of bond paper. The vellum has an added resin compo- 
nent that fills in the voids between the fibers to impart the 
translucency to the sheet. This results in a sheet that has 
essentially no porosity compared with the relatively porous 
plotter bond. This further reduces the ability of the ink sol- 
vents to migrate into the sheet. In addition, some transpar- 
entizers, as the resins or oils are called, are not compatible 
with the thermal inkjet inks. The project required under- 
standing the thermal inkjet ink chemistry interactions with 
various transparcntizers and selecting the best transparentizer 
for the best print quality on pen and thermal inkjet plotters. 

As with the bond paper, extensive testing of the existing 
velluni was undertaken to determine the desired physical 
characteristics. The data was used to develop a model for 
the vellum similar to that for the bond paper. The vellum 
manufacturer used this information to develop a vellum 
that not only provides excellent print quality on the thermal 
inkjet plotter but also has improved characteristics on pen 
plotters. 

These products, along with the remainder of the media set, 
were exhaustively tested under a variety of environmental 
conditions on the DesignJet plotter to ensure Hewlett- 
Packard quality for our customers. 

DesignJet Media Bin 

The Designjct plotter provides "unattended plotting." This 
involves handling multiple output sheets with no user inter- 
vention. The user should bo able to pick up a finished plot 
Without the added inconvenience of unrolling and hand-cut- 
ting a plot, or picking it up from the floor. We needed to go 
beyond the usual catch tray, which could wrinkle or damage 
the plot. The DesignJet plotter provides an automatic one- 
axis cutter that will trim the plot to the right length after 
plotting from a roll. The trimmed sheets are then handled by 
an automatic sheet slacking system that won't damage the 
plots. This function is provided at a low cost increment. 

System Requirements 

To define the media slacker requirements, we conducted 
user surveys, surveys of the media distributors, and focus 
group studies, From the collected data, we created a typical 
user model and determined the following requirements for 
the media stacker: 

It should work with popular media from most manufacturers. 
It should work with media sizes from G size or equivalent 
up to E size or equivalent. 

It should work with all media types, including vellum, chart 

paper, translucent, and polyester film. 

It should work under a wide range of environmental 

conditions. 

It should not exceed the footprint of the machine because 

of space constraints in the office environment 

It should have low incremental cost. 

It should stac k up to 20 sheets without user intervention. 

Because it would have been impractical to test all of the 
possible media permutations, we defined a representative 



media sample front the most popular manufacturers to be 
evaluated and tested. 

Design Considerations 

Cost. time, and available resources pointed toward a passive 
system. This implied that system performance would be 
heavily influenced by the behavior and properties of the 
media. 

We identified the critical properties that would affect a pas- 
sive system and then proceeded to characterize these proper- 
ties at extremes of temperature anil humidity because the 
physical propert ies of most media types change drastically 
under different environmental conditions. We also looked at 
the inherent properties of roll media, since rolls are the media 
format used during unattended plotting (cut-sheet mode re- 
quires the user to load and remove plots individually, unlike 
roll mode, in which plots are automatically cut and stacked). 

Media Properties 

Curl-Set. Curl-set is curvature induced in the media because 
of internal stresses as it is deformed to wrap around the 
core of the roll. This induced curvature is more pronounced 
closer to the core because it is proportional to the radius of 
the core and the tension used to wind the media around the 
core. We characterized curl-set as a function of sheet posi- 
tion within the roll, and we also measured curl-set relax- 
ation as a function of time. Curl-set is affected by tempera- 
ture and humidity, so we tested at extreme environmental 
conditions (see Fig. 9). A section of roll media with curl-set 
so pronounced that it lends to roll on itself once the sheet is 
cut is considered not stackable. We found that the stackable 
portion of the media roll varies considerable from roll lo 
roll, and from media type to media type. It appears thai 
many media vendors do not have good control over roll- 
winding tension, which affects curl-set direc tly, so different 
rolls vmy from 100% to 6094 in the percentage of their length 
that is stackable. The amount of curl-set relaxation over time 
is not enough to make a difference in media performance. 

Friction. We measured the friction coefficient of the repre- 
sentative samples to try to determine the optimal slide angle 
for t his type of slacking system. Fig. 10 shows curves of tray 
depth as a function of slide angle for 44-inch sheets. Tin' 
optimum angle is where the depth is a minimum. This angle 
varies with the coefficient of friction. 

Ink Dry Time. The ink dry time is the lime required for the ink 
to diy once it is applied to the media. This is an Important 
parameter because we needed lo be sure that the ink will be 
dry by the time it touches the ramp of the media stacker or 
other sheets, so thai the plot won't smear. 

Stiffness. The rigidity of the sheet as it is feed from the plot- 
ter lo the slacker affects the geometry required lo guide I he 
media properly. Moisture content affects stiffness lo a con- 
siderable extent. Some media samples could collapse before 
being stacked because of reduced stiffness. 

Geometry and Operation 

To keep the media stacker bin within the limits of the plotter 
footprint* we devised a ramp that inverts the sheet direction 
under the machine. 
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Fig. 9. Curl-set and curl-set relaxation measurements for various media types. Curl height as a function of sheet number Tor (a) HP Paper 
(h) JH<i vellum V-20 (c) Clearprint KIOOH vellum. (44-inch sheets. Sheet 1 is on the outside of the roll.) (d) Curl height as a function of 
time for Clearprint lMKiM vellum. 



The principle of the system is to guide the sheet using a 
ramp at a relatively steep angle into a stop. The sheet is then 
allowed to form a loop outside the ramp as it is fed. so thai 
when the sheet is cut. the weighl and position of the loop 
induce it to fold outward, so that Half of the sheet ends up 
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Fig. 10. Measurements of depth versus slide angle for the DesignJet 
Ha stacker. 



inside the bin and the other half hangs on the outside. Sub- 
sequent sheets follow the same path and are stacked on top 
of the previous sheets (see Fig. 1 1 ). 

To handle curled media from a roll, we devised a feature 
close to the bottom of the bin to serve as a stop for the curl- 
ing media. If the media is considerably curled, the leading 
end of the sheet will tend to curl on itself When the sheet is 
cut. it will collapse into a roll. The stop feature stops the 
leading edge before it curls on itself (see Fig. 12). 

The parameters that have a first -order effect on stacking are 
bin depth, the position of the bin relative to the output gap, 
and inclination angle of the ramp. These parameters can be 
optimized for a particular media type and length of sheet. 
Unfortunately, there are large variations in media properties 
and dimensions. We compromised the geometry of the sys- 
tem so that it would function with the most popular com- 
binations of media type and sheel length, and we provide a 
three-level depth adjustment to handle different sheet 
lengths. 



14 December \\nt\l Hewlett-Packard l"iin@lCopr. 1949-1998 Hewlett-Packard Co. 





Fig. IL Operation oftlie DesignJet media starker. 





6~ 



Acknowledgments 

The DesignJet development team was highly dedicated, pro- 
fessional, and motivated. The team members worked together 
well and respected the values that each area of expertise 
brought to the program. In addition to the people mentioned 
in other articles in this issue, the authors would like to thank 
the following for their notable contributions beyond the call 
of duty: Alecia Jay and Nancy Helff for the great manuals 




Curl Set 



and user need studies, Dan Goese, Andy Tallion, and Steve 
Flack for the great marketing support they gave the program. 
Sharon Jensen. Joe Milkovits. Dan ( aputo, Russ Bergen, Rob 
McClinc. Rick Hermes. Katherin Ault. Scott England, Carey 
Enslow, Nancy Huelsmann, Adrian Huges, Nils Madden, 
Vinh Nguyen. Richard Szapacs, and Warren Werkmeiser for 
the excellent job they did in working with our suppliers and 
making sure that quality and delivery were priorities. Rod 
Degesero for the product packaging, which has proven itself 
capable of standing up to the worst transportation abuse, 
Irene Caravantes, Mike Duffy. Sandra Boldt, Vern Hudson, 
Cameron Light. Donna Ogilvie, Virginia Pollack. Jusitine 
Prehatney, Carey Ramos, Bob Stuart, and Christine St. Ives 
for the work they did in creating market visibility and mar- 
ket support. Tor the product, Peter Morris. Bruce Mueller, 
and Allison Rap for getting our consumables in place. Rick 
Brown and Andy Tricario for the production support they 
gave during the design phases, and Stephen Glass, Trade 
Middlelon, Scott Bonnet, Tom Barker, and Scott Roleson for 
the excellent role iliey played in making sure the product 
met worldwide agency approvals and in ensuring that the 
product meets customer expectations. Glenn Gaardcr. Don 
lliler, Lynn Palmer, Jeff Stong, Darren Wilcox, and David 
Walker are additional mechanical engineers who contribute!! 
to the program greatly. 



Fig. 12. i m l stop functioning. 



© Copr. 1949-1998 Hewlett-Packard Co. 



December I9B2 Hewlett-Packard Journal 15 



Electronic and Firmware Design of the 
HP DesignJet Drafting Plotter 



High-performance vector-to-raster conversion and print engine control are 
provided by a RISC processor, two single-chip processors, and three 
custom integrated circuits. Development of the electronics and firmware 
made extensive use of emulation and simulation. 

by Alfred Holt Mebane IV, James R. Schmedake, lue-Shuenn Chen, and Anne P. Kadonaga 



The IIP DesignJet raster InkJet plotter project required con- 
tribiitions in the design of veetor-to-raster conversion and 
print engine electronics. The project was constrained by 
cost and schedule, but the performance of the vector-to- 
raster converter and the inkjet print engine was considered 
of prime importance in meeting our user's needs. Our tradi- 
tional approach t o plotter elect ronics, while meeting cost 
and schedule goals, would have fallen short of the required 
performance goals. Existing electrostatic vector-to-raster 
converters, while meeting performance goals, were too 



expensive for our market. The approach we took was a 
fresh look at the requirements of both the vector-to-raster 
converter and the print engine. 

Vector-to-Raster Converter 

Two major tasks are performed by the vector-to-raster con- 
verter. The first is HP-GL/2 language parsing. The second is 
conversion of the parsed objects into the dot patterns 
printed on the page. In the DesignJet plotter, these two 
tasks are serial and do not occur simultaneously. 
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Fig. 1. Elei trunic block diagram of the HP DesignJet large-format inkjei drafting plotter. 
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An early decision was made to include the vector-to-raster 
converter in the base machine electronics even though sev- 
eral low-cost competitive raster products omit this feature. 
The design team felt that a vector-to-raster converter could 
be integrated together with the print engine control logic at 
a reasonably low incremental cost. The major constraint 
placed upon this implementation was that it be of high 
enough performance to outpace the print engine in all but 
the most complex plots. It was acceptable to slow the print 
engine during very complex plots, but only for the affected 
carriage scans. 

Initial investigations centered on the use of specialized 
graphics processors. These processors were more than ade- 
quate for the rasterization of lines, but were far too slow 
when parsing HP-GL/2. Next, an approach was investigated 
in which a general-purpose processor performed the parsing 
and print engine control while a graphics processor did only 
the raster conversion. The fundamental weakness of this 
approach is the cost of using two processors even though 
only one is required at any point in time. 

The final design is based on a single, high-performance, 
RISC processor for both print engine control and the two 
vector-to-raster converter functions. The selection criteria 
were cost, a performance benchmark based on an existing 
HP-GL/2 parser, and an engineering estimation of potential 
raster conversion performance. The Intel 80960KA was se- 
lected from the available choices, which included both RISC 
and CISC microprocessors. Although they were not part of 
the original criteria, two other features of the 80960KA made 
it attractive in the DesignJet application. The first of these is 
the multiplexed address and data bus, which reduced the 
pin count on the application-specific integrated circuits 
(ASICs) that were being designed for the product (see 
"Desigalet ASIC Development" on page 18). The second is 
the existence of the 80960 KB processor, which includes 
hardware floating-point capability. If at any lime during the 
project the need for faster floating-point performance had 
arisen, the -KA version could have been replaced by the -KB 
version without any circuit board changes. 

The remainder Of the processor portion of the electronics 
consists of 2M bytes of DRAM, 1M byte of ROM, I/O. and 
DRAM memory expansion. A processor support ASIC in this 
section provides a DRAM controller, wait state timing for 
both RAM and ROM, interrupt control, and 809150 reset 
synchronization. This ASIC is described later in this article. 

Fig. 1 is the electronic block diagram of the MP DesignJet 
plotter. 

Input/Output 

The DesignJet plotter was originally defined as a plotter 
solution for pen plotter users who require greater through- 
put on monochrome plots. This definition suggested incor- 
poration of the three built-in I/O ports— RS-232-C, HP-IB 
(IEEE 488, IEC 625), and printer parallel— that are included 
in existing HP plotters. The Desigalet R&D team decided to 
pursue a more flexible approach. A strategy thai had been 
adopted lor the l-iserJet FUSi printer was investigated in 
which there is no built-in I/O but instead a standardized, 
iiu ii lular I/< > slot (MIO) capable of accepting many different 
types of I/O options. Alter reviews with manufacturing and 
service representatives it was decided to keep the RS-232 



and parallel interfaces built-in to allow the DesignJet plotter 
to leverage existing test and repair systems. The built-in 
HP-IB port has been replaced with an MIO slot to allow the 
DesignJet plotter to use some of the I/O options developed 
for the LaserJet DlSi. At introduction both the HP-IB and 
Novell Ethernet were available options. 

Memory' Expansion 

One of the more difficult specifications to set for the Design- 
Jet plotter was DRAM memory size. In a pen plotter, each 
vector is strobed out as it is received, so plotting can begin 
as soon as the first vector is parsed. The DesignJet plotter 
must parse and store all the incoming vectors before making 
the first carriage sweep. It is an inconvenient feature of vec- 
tor languages that the last vector received may cross the 
portion of the page covered by the first carriage scan. This 
leads to a limitation on plot complexity based on the mem- 
ory size available to store parsed vect ors. The trade-off is 
the cost of memory versus the complexity of the possible 
plotted images. Hewlett-Packard electrostatic plotters solve 
this storage problem by means of magnetic disk storage. 
The drawbacks of a Desigalet implementation of a similar 
solution were cost and the difficulty of providing a mechani- 
cal mounting to allow a disk drive to survive the shipping 
and operating environments expected for the DesignJet plot- 
ter. The chosen solution is industry-standard, 72-pin single 
inline memory modules (SIMMs). This memory is added in 
the form of LVI-byte or IM-byte SIMMs, which are available 
from IIP for a variety of products in the personal computer 
and peripheral areas. Two sockets are available under a panel 
in the rear of the plotter. Addition of two 4M-byte SIMMs 
gives a user an additional 8M bytes of vector storage for com- 
plex plots. The use of SIMMs for memory expansion adds 
very little cost for users with needs fining into the standard 
2M-byte RAM and provides a relatively low-cost upgrade 
path for users requiring more. 

Print Engine Control 

Prinl engine control is a much less demanding task than 
vector-to-rastcr conversion. Print engine control includes 
two-axis servo motor control, front-panel control, keyboard 
scanning, front-panel display update, optical sensor scanning, 
and thermal inkjet pen service station control. 

The servo motor control functions of position decoding and 
pulse width modulation of the motor voltage were added to 
the processor support ASIC. The other functions required 
mostly pins with very little logic, so alternatives were inves- 
tigated that could implement them more efficiently. The re- 
sult of this investigation is an approach thai surprised most 
of the design team. A single-chip processor, the Intel 8052, 
was able lo perform these functions with a lower production 
cost than an ASIC and for a fraction of the development cost. 
It also performs all of the real-time servo control, offloading 
this from the 80960KA. 

The 8052 is designed into the architecture as a slave proces- 
sor lo the 80960KA A bidirectional command and mailbox 
port is implemented in the processor support ASIC to allow 
processor-to-processor communication. Through this port 
the 8052 is able to return data lo I he 80960KA in response to 
commands or to generate one of several interrupts. Among 
these interrupts is the operating system time slice Interrupt 
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A vast portion bf print engine control is the electronics re- 
quired to support (he thermal inkjel pens. The most difficult 
function performed In this area is the mapping from the 
image generated in memory hy the vector-to-raster con- 
verter to the series of timing pulses sent to fire the pens. 
This task is made difficult hy the fact that the DesignJet 
plotter uses two 50-nozzle pens that are not accurately 
aligned mechanically with each other. The mapping attd 
alignment compensation are performed hy two ASICs, one 
located on the main hoard and a companion part located on 
the circuit hoard that travels on the pen carriage. The two 
ASICs are connected hy a serial link that runs through the 
trailing cahle. The pen interface ASIC on the main board is 
initialized with the measured distances between the two 
pens and is able to select from image memory all the dot 
positions that are covered by pen nozzles at a given carriage 
position. As the carriage scans across the page. I his ASIC 
sends groups of 100 bits up the serial link to the carriage 
ASIC at 1/300-inch intervals. The carriage ASIC buffers the 
100 bits and creates the liming patterns used as inputs to the 
drivers that generate the firing waveforms for the thermal 
inkjel pens. 

Pen Calibration 

Offsets between the two pens are measured hy another set 
of electronics located on the carriage board ( see article, 
page 2-1 ). DesignJet pens are aligned by drawing a series of 
patterns on a page and then using an optical sensor to mea- 
sure the relationship of pat terns drawn with one pen to the 
patterns drawn by the other. These offsets are written to the 
thermal inkjet support ASK s as described in the paragraph 
above. The electronic components of the optical system are 
controlled by an 8051 microprocessor located on the carriage 
board. The decision to use the 8051 on the carriage is based 
on the same criteria used to select the 8052 for the main 
hoard — the 8051 can perform the sensor control functions at 
a lower part cost and a much lower development cost than a 
special-purpose ASIC. An added feature gained by using the 

8051 is that it provides the serial communication path to the 

8052 on the main board. This communication path is used 



both for the optical system and for sending pen firing 
constants to Ihc ASIC on the carnage. 

DesignJet ASIC Development 

Often the custom IC design is in the critical path of elec- 
tronic systems development. This was the case for the HP 
DesignJet plotter project. Three ASICs were needed to pro- 
vide the necessary functionality and performance in the 
DesignJet plotter at a low cost. 

The main challenges were clear right from the beginning. 
The team had to deliver three working ASICs on schedule. A 
turnaround in any of the ASICs would have meant a serious 
schedule slip, since the fully functional ASICs were needed 
to start much of the system-level testing. The team also had 
to provide the functionality of these ASICs before the first 
silicon became available to enable parallel development of 
tin- printer mechanisms and firmware. These needs had to 
be met with a limited number of engineers and a given 
budget to avoid adversely affecting other projects. 

Processor Support ASIC 

The processor support ASIC interfaces to both the main 
processor (80!)(i0KA) and the servo processor (8052) and 
performs various assist functions for each processor. The 
block diagram of the IC is shown in Fig. 2. The main proces- 
sor side of the processor support ASIC consists of the 
80900KA interface, the DRAM controller, the serial I/O inter- 
face, and the fire pulse controller. On the servo processor 
side, the IC contains the 8052 interface and the motion con- 
troller. The processor Support ASIC also provides two 
ntodes of communication between the processors: a polled, 
bidirectional mailbox and an interrupt -driven, unidirectional 
block transfer buffer. 

The 80960KA interface assists the processor during burst- 
mode ROM and DRAM accesses and handles the queueing 
and prioritizing of the incoming interrupts. The DRAM con- 
troller supports up to 20M bytes of memory of different sizes 
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and access times. The serial 1/0 interface consists of a baud 
rate generator and a I' ART ( universal asynchronous receiver/ 
transmitter). The fire pulse controller generates a synchroniz- 
ing pulse for each column of pen data. The output is extrapo- 
lated from the carriage position encoder counts ai one, two. 
or four times the frequency. 

The motion controller decodes the position information for 
the carriage and paper axes. It also generates the PWM 
(pulse width modulation ) signals for the dc motor drivers as 
needed for servo control of the carriage and paper axes. A 
watchdog timer monitors the servo loop and disables the 
PWM outputs in the event of a servo processor malfunction. 
A status register is also provided to log various motion 
control error conditions. 

Pen Interface ASIC 

A shuffler stage is needed to map the row-oriented image 
data into the column-oriented DeskJet pen nozzle data. In a 
departure from previous shuffler designs, the pen interface 
ASIC uses a dedicated external memory array to store its 
own copy of the image data and a programmable internal 
sequencer array to hold the shuffle pattern. The shuffling is 
done by copying an entire swath of image data from the sys- 
tem memory into its local memory and fetching the pixel data 
for each pen fire sequence according to the preloaded shuffle 
pattern. This approach offloads these tasks from the main 
processor bus and allows greater flexibility for supporting 
different pen nozzle configurations. 

The pen interface ASIC contains three bus interfaces: the 
main processor (809G0KA) bus, the swalh memory interface, 
and the serial link to the carriage ASIC. The block diagram 
of the pen interface ASIC is shown in Pig. 3, In the copy 
mode, the data and address path from I he main processor 
interface to the swath memory is enabled. The pixel counter 
counts the number of pixels to be printed, and its output is 
used to calculate the plot density and ink use. In the shuffle 
mode, the path from the swalh memory to the serial inter- 
face is enabled. The serial dala transmitter assembles the 



pixel data fetched from the swath memory for each fire se- 
quence into a serial bit stream and sends it to the carriage 
ASIC. The pen interface ASIC and the carriage ASIC contain 
identical pixel checksum counters to check the integrity of 
the serial transmission. 

The pixel address generator is the heart of the pen interface 
ASIC. It consists of an SRAM array for the programmable 
sequencer, a logical column counter, and an adder. The se- 
quencer is preloaded with the pixel address offsets for each 
pen nozzle of a fire sequence. The offsets contain the col- 
umn adjustment delays for pen alignment correction (see 
article, page 24). A mask patient is tagged onto each entry 
to aid different print modes. The column counter is either 
incremented or decremented depending on the print direc- 
tion, and its content is added to the pixel address offset 
from the sequencer to generate the physical DRAM address 
of each pixel's data 

Carriage ASIC 

The carriage ASIC resides on the printed circuit board that 
is mounted on the moving pen carriage assembly. Its pri- 
mary function is to generate the data and address signals for 
the pen driver ICs. The relative timing and the pulse widths 
of these signals arp carefully controlled to adjust the pen-to- 
pen offsets, the bidirectional offsets, the pen-to-paper-axis 
deviation errors, and the pen turn-on energy variations. 

The carriage ASIC contains three bus interfaces: the carriage 
processor (8052) bus, the serial link from the pen interface 
ASIC, and the pen driver IC interface. The block diagram of 
the IC is shown in Fig. 4L The processor bus is used to ac- 
cess the timing control registers. The serial data from the 
pen interface ASIC is shifted into a serial-to-parallel con- 
verter. A checksum counter monitors the serial input dala to 
verify the integrity of the serial link. A parallel pipeline regis- 
ter follows the shift register to provide the double column 
buffering. The buffer outputs are divided into four delayed 
pipeline registers, each of which is delayed by the value in 
ils corresponding delay time register. Each of the four data 




© Copr. 1949-1998 Hewlett-Packard Co. 



ripcemixT i!«i2 Hewlett P*ckard Journal 19 



Carriage iC 



8051 Bus 



/ FIRE 



From Pen 
Interface 
IC 




Checksum 
Register 



Pen 1 Upper Address 
Pen 2 Upper Address 
Pen 1 Lower Address 
Pen 2 Lower Address 



Pen 1 Upper Data 



Pen 1 Lower Dala 



Pen 2 Upper Data 



To Pen 
Driver IC 



Pen 2 Lower Dala / 



Fig. 4. Carriage ASK' block diagram. 

multiplexers selects the data lo he driven for one hall' of 
earli pen. 

Design Approach and Tools 

Behavioral Simulation. The Bluffier algorithm implemented in 
the pen interface ASIC and the carriage ASIC is a completely 
new design for any IIP product. The shuffle path from the 
image data in the system memory to the pen outputs in- 
cludes many hardware blocks and spans several different 
bus interfaces. The need to verify the correctness of the 
Shuffler algorithm at a high level before any hardware de- 
sign was apparent. A behavioral model of the algorithm was 
written in the C programming language. A graphics driver 
was added for both the input image data and the pen out- 
puts. A complete graphical animation showed both the 
image data and the printed data as the pen swept across the 
screen. Any error in the shuffler algorithm was observable 
right on the display screen. This high-level verification ap- 
proach turned out to be very valuable. The shuffler algo- 
rithm was completely debugged during the simulation phase 
before any hardware was designed. 

Emulator Strategy. It was decided to build emulators for the 
three ASICs despite the substantial amount of additional 
resources required. As mentioned earlier, the functionalities 
of the ICs were needed before first silicon to enable parallel 
development of the printer mechanisms and the firmware. 
The emulators were able to meet this need. If there had 



been a major hug in the first silicon, the emulators could 
have continued to provide the necessary hardware platform 
ai least for firmware development if not for further mechani- 
cal integration and system testing. Another important con- 
sideration was thai in the absence of a system-level simula- 
tor, the emulators combined with the rest of the electronics 
supplemented the chip-level simulation in the overall func- 
tional verification effort. The emulators also proved very 
useful in isolating and diagnosing anomalies encountered 
while integrating the first silicon into the system. 

The emulator for each IC presented a unique set of design 
requirements. The major problem for the processor support 
ASIC was the schedule because of its late start and com- 
plexity. To keep pace with the other two ASICs, much of the 
emulator and IC design was done in parallel. The emulators 
for both the processor support ASIC and the pen interface 
ASIC required fast, hence low-density, PAL (programmable 
array logic) parts to meet the 16-MHz clock frequency re- 
quirement. The processor support ASIC emulator consisted 
of fast PALs, standard logic parts, and a CART The pen in- 
terface ASIC emulator used fast PALs for most of the logic 
and a high-speed SRAM for the pixel address sequencer. The 
swath DRAM parts, which reside outside of the IC, were 
also included in the emulator to avoid electrical problems 
related to board interconnects. The requirements of the car- 
riage ASIC emulator were a large number of registers and a 
small board area. The slower clock frequency of 12 MHz 
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allowed the use of high-density field-programmable gate 
arrays, which offered a large number of flip-flops per part. 

Vendor Selection. After a preliminary screening of many ASIC 
suppliers, several vendors of both standard cell and gate 
array parts were closely evaluated In addition to nonrecur- 
ring engineering charges, cost per part, and prototype lead 
time, also considered were the availability and cost of the 
hardware and software toolset, the quality of the technical 
support during development, and expected responsiveness 
after release to production. We decided that all three ASICs 
would use the same vendor and toolset for both technical 
and logistical reasons. We chose the CMOS34 standard-cell 
technology of the IIP Circuit Technology Group, which of- 
fered the LogicArchitect ASIC development toolset, some of 
which is described below in more detail. The vendor also 
delivered the I'ART megaceU for the processor support 
ASIC and the SRAM array for the pen interface ASIC. 

Logic Synthesis. A logic synthesis tool was used extensively 
for transforming the control logic into the standard cells. 
The automation of this laborious task not only saved much 
time during the initial mapping of the logic into a combina- 
tion of gates but also reduced the number of iterations 
through the compose-verify -correct loop. The synthesis tool 
was also used to generate the custom registers, decoders, 
and multiplexers. This approach was preferred over the use 
of TTL macro cells* because it made it possible to imple- 
ment only the necessary functions using minimum-area cells. 
TTL macro cells were used for such blocks as counters, 
where they could be modified to provide only the necessary 
functions with the minimum-area cells. 

The synthesis tool also offered area-versus-delay optimiza- 
tion capability, but this was of limited use for most blocks 
because the CMOS34 process is fast relative to the clock 
frequencies of 10 MIIz and 12 MHz. In many cases, setting 
the area constraint at minimum sufficed, The exceptions 
were in control blocks where both the rising and falling 
edges of I he clock were used, effectively doubling the fre- 
quency, and some critical timing path blocks. For these 
blocks, the delay constraint was set as needed with some 
margin. The worst path delay estimates included in the re- 
port files were useful in quickly verifying the timing margins 
at the block level. 

Timing Analysis. Unlike a functional simulator, which re- 
quires a set of test vectors to exercise the circuit to verify 
the delay liming, a static liming analyzer calculates I he de- 
lays through the specified paths based on the circuit struc- 
ture alone. The static timing analyzer of the bigicArchiteci 
toolset, complemented the functional simulator by rapidly 
searching through the circuit delay paths before any test 
vectors were written. It was used to identify any unexpected 
critical timing paths and to verily the margins in the known 
critical liming paths. This lool was especially useful in deter- 
mining the margins in input Setup times and output delay 
times with respect to the clock edges. 

Functional Simulation. As expected, the functional Simulation 
took a major chunk of the tolal IC design time. A lest vector 
generation interface in (he LogicArchitect loolsel saved a 

Most ASIC vendors oiler macro cells lor widely used oll-theshell logic pans such as TTL 
parts A macro cell is 8 collection o( library standard cells and irneiconiieclinns ttiat performs 
ihe same function as the corresponding off-the-shel! logic part 



great deal of time by allowing the test vectors to be as- 
sembled from the subroutine functions and macros. Distrib- 
uting the simulation jobs among various workstations also 
helped. Although the blocks were simulated at all levels in a 
bottoms-up order, the emphasis was different at each level. 
For example, once a comparator was verified at a low level 
with a semiexhaustive set of input combinations, it was not 
subjected to another input combinations test at a higher 
level. Instead, more time was spent exercising its interaction 
with lite control logic. At the top level, special care was 
taken to set the correct input and output timing values and 
to choose the right types of load and delay models. A full set 
of top-level test vectors was repeated with the capacitance 
values extracted from the layout, and a special check of 
paths with potential skews was done. 

Design for Testability. Three types of test support circuitry are 
designed into Ihe DesignJet ASICs: scan paths for the auto- 
matic generation of the stuck-at fault test vectors, a bound- 
ary' scan path in the carriage ASIC, and pad instate control 
Tor Ihe board testers. The HP CMOS34 standard cell method- 
ology offers automatic test generation capability for stuck-at 
faults. The estimated hardware overhead for providing the 
necessary scan paths was about 10%. The designers of all 
three ASICs decided to support automatic test generation to 
achieve the highest possible fault coverage with the mini- 
mum of test vector generation effort. The scan paths were 
created by replacing each flip-flop with a scannable type and 
providing scan controls. Special controls were designed for 
the flip-flops clocked on the opposite edge of the clock, for 
bidirectional buses, and for asynchronous signals. A bound- 
ary scan path is implemented in Ihe carriage ASIC to drive 
the output pads directly, bypassing the complicated internal 
configuration. The trislate control is provided for all pad 
drivers on each ASIC to allow the board tester to drive the 
IC pins directly. 

ASIC Results 

The DesignJet ASIC development team delivered the three 
fully functional ASICs on schedule. All three ASICs were 
released to manufacl tiring without any design changes. The 
processor support ASIC, packaged in an 84-pin PLCC (plas- 
tic leadless chip carrier), has the equivalent of 1 1,000 gates 
and a die area of 4.9(5 by 5.90 mm. (One equivalent gate rep- 
resents four transistors needed to implement a two-input 
NAND gale.) The pen interface ASIC, also packaged in an 
84-pin PLCC, came in at 4,000 gales and a die area of 4.87 by 
6.56 mm, including the SRAM array. The carriage ASIC, 
packaged in a 08-pin PLCC. has a final gate count of 10.000 
and a die area of 4.92 by 5.24 mm. 

Each ASIC was successfully integrated into the system 
within a day of Ihe arrival of the first silicon. This was pos- 
sible partly because the system was already debugged using 
the ASIC emulators. Willi further code development later, a 
few corner-case problems that required minor firmware 
workarounds were uncovered. No other functional or elec- 
trical problems were found. This proved that our design 
approaches and the toolset were basically sound, but 
needed improvement in testing Ihe comer cases. Even with 
the IC emulators, the comer-case testing was difficult be- 
cause the code development continued well pasl the IC tape 
release. A collaborative effort by the ASK ' and firmware 
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designers involving their respective toolsets would help de- 
velop a better functional verification strategy. The design for 
testability allowed quick deslaffing of the ASIC design leam 
because no additional fault coverage test vectors were 
needed after the tape release. 

DesignJet Firmware Development 

The use of the Intel 809G0KA processor in the DesignJet 
plotter created several development challenges for Ihe firm- 
ware design team. First, hardware to exercise the code 
would not be available for several months after coding had 
begun. Second, the S0900 was a new processor to our divi- 
sion, so we needed to stall almost from scratch on our de- 
velopment system. Third, we had extremely limited person- 
nel resources and time to perform the necessary tasks. In 
the past, a main source of schedule investment was in Ihe 
integration of independently developed code sections and 
the correction of timing problems between these indepen- 
dent sections of code. In addition, we generally spent much 
time tuning ( if not totally redesigning) Ihe user interlace of 
the plotter once the code was integrated into ihe target. For 
the DesignJet project, we needed to minimize this largely 
nonproductive use of time. The solution was lo build a de- 
velopment environment that was largely independent of Ihe 
hardware, in leverage code and algorithm designs from out- 
side groups, anil to debug our code at the source level on 
both the targe) and host (simulator) systems. To ease in- 
tegration and help wilh timing-related bugs, we chose to use 
an internally developed full-featured operating system. 

Development Environment 

The DesignJet development environment was different from 
any environment our division had used in the past. On past 
projects, almost all firmware engineers used a target-based 
emulator for all development work. Hardware was generally 
reused from pasl projects to inn the emulators in an envi- 
ronment that closely matched the new system. Much of our 
past work had been done in assembly language. Therefore, 
Ihe use of emulators was really a method of "source-level" 
debugging. On the DesignJet plotter project, our lack of 
hardware limited the use of emulators. In addition, there 
were no emulators available thai interfaced with our IIP 
9000 Series 300 workstations, which were used for compil- 
ing and linking. These restrictions forced us to reconsider 
our past development methods. We decided that our code 
should run. as much as possible, on both our target system 
and our workstations. Since our coding was to be almost 
100% in the C language, we maintained object modules com- 
piled both for Ihe target and workstation, or host, systems. 
Only where there were differences between the two systems 
was there any addit ional code to support the host system. 

The main difference between the host and target systems 
was in the I/O and print engine subsystems. The I/O subsys- 
tem was easily modified lo accommodate a host-based de- 
velopment system. The main input path was set up such dial 
when running on the host, input was done from the host file 
system rather than a Centronics or RS-232 port. None of the 
code outside of one function "knew" where input was origi- 
nating. The print engine that ran on the target was almost 
identical to the print engine on the host. The main difference 
was where to send data to print. On the target, hardware was 



Ihe destination of completed bands, or swaths, of print en- 
gine data. On the host, a simulator was used. We obtained an 
X Window-based simulator that we were able to modify for 
our use on the Desigalet plotter. The simulator was passed 
an array of bitmap swaths, and when so Instructed, opened 
an X Window on the workstation to display Ihe data. The 
simulator had Ihe ability lo highlight individual swaths, scale 
ihe bitmap, and zoom in on specified areas of ihe bitmap. 
This allowed inspection of plotter output at Ihe individual 
dot level, something that would have been next to impossi- 
ble to do accurately on the target system. The simulator 
allowed all development of nontarget-specific code to be 
done on the host, especially debugging using cdb and xdb. 

I-arge-fonnal plotters require much interaction with Ihe user, 
particularly in the areas of front-panel control and media 
loading. The front panel was developed with the aid of a 
front-panel simulator that ran on a PC. This important area 
of the user interface was then designed independent ly of the 
hardware and firmware of the plotter. The front-panel simu- 
lator was designed such that nonfinnvvare personnel, such as 
marketing and user interface experts, could design and fine- 
time their own front panel. This freed a firmware engineer 
to work on other tasks. 

The media-loading interaction w 7 as also subject to a great 
deal of modification. The basic loading algorithms were de- 
veloped by mechanical engineers on simple breadboard me- 
chanics. These generic motor controllers allow nonfirmware 
engineers to control motors precisely with simple HP-GL- 
like instructions from any computer. Typically, a mechanical 
engineer wrote BASIC programs on an HP 9000 Series 200 
computer to develop media-loading sequences and algo- 
rithms. The generic motor controllers have general-purpose 
inputs and outputs, thus allowing the development engi- 
neers access to sensors and actuators as desired. Offloading 
these types of development activities allowed the firmware 
engineers to focus on software engineering problems. When 
algorithms were basically complete, the mechanical engi- 
neers documented their work graphically, allowing the firm- 
ware engineer to translate Ihe algorithm into Ihe Design-lei 
framework. 

Code Reuse 

A major pott ion of any print er or plotter is the language sub- 
system, in our case HP-GI/2. On the DesignJet plotter, we 
clearly did not have the resources to reinvent this wheel. We 
were able to use a language subsystem developed at our 
division thai had been previously used on several products, 
including the LaserJet 111 printer. This proved lo be ex- 
tremely beneficial in several respects. Certainly, the time 
spent integrating this code was much less than would have 
been necessary to rewrite it. The most beneficial aspect, 
however, was that far less lime was needed in testing be- 
cause the code had already been thoroughly tested and de- 
bugged in previous products. This gave us the high-quality 
language subsystem that we wanted with a minimum of in- 
vestment in time from our product team. A second area that 
was heavily leveraged was the vector-to-raster convener. 
The basic high-performance design that had been used in 
other raster products from IIP was leveraged for the Design- 
Jet plotter. While the original vector-to-raster converter was 
written in assembly language, we chose to rewrite the code 
in C. The previous products had used a different processor. 
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so rewriting the code was necessary anyway. Using C, reuse 
in future products would be far easier no matter what 
processor might be chosen. 

Debugger 

The lack of emulators on the target system required the use 
of a new tool for our division: the retargetable remote de- 
bugger. We found that the GENU debugger. gdb960. worked 
very weD on our system. gdb960 was developed by both The 
Free Software Foundation and Intel for use on the 80960. 
This source-level debugger uses a simple monitor on the 
target system while the main debugger runs on the host 
Communication for debugging is via RS-232. We modified 
the monitor code so that we could download executable 
modules to the target system via our built-in Centronics in- 
terface. The monitor program. NINDY. was supplied by Intel 
and modified by us for our hardware. The modifications 
were minimal and were only in those areas of the code that 
dealt with serial I/O and dow nloading. The download capa- 
bility was modified because the default method, RS-232, was 
too slow. With Centronics downloading, we were able to cut 
download times from about 10 minutes to about 10 seconds. 

Using gdb960, we were able to resolve problems that ap- 
peared only on the target very quickly. The debugger func- 
tions much the same as the debugger cdb of the HP-UX* 
operating system. With our remote-reset and login capabil- 
ity, we were able to debug target-executing code from home 
on those nights when long hours were called for. The debug- 
ger is completely source-level; that is, breakpoints are set on 
C source lines, not particular addresses. Structures and 
arrays print as such; there is no need to examine memory 
addresses and reconstruct the data types of interest. If a bug 
manifested itself as a processor fault, the debugger showed 
us the entire stack frame and allowed us to move about 
within stack frames. This enabled us to find the real source 
of a problem, which was often several stack frames up from 
the fault itself. In short, debugging on the target was generally 
no more trouble than debugging on the host. 

Operating System 

At the outset of our design cycle, we determined that use of 
a formal operating system would be beneficial in two ways. 
First, it would provide a stable interface for interprocess 
communication. This would ease the process of integrating 
code that had been developed independently by several 
firmware engineers. Second, since the operating system we 
used was a preemptive operating system, timing problems 
typical of custom operating systems would be greatly re- 
duced. Rather than invest in methods and hardware to de- 
bug complex timing problems, we decided to invest in an 
operating system that would prevent these problems. While 
sounding overly simplistic, this logic turned out to be quite 
accurate; we had very few timing-related problems. In addi- 
tion, when hardware became available, code integration went 
very smoothly. There were very few problems with interface 
specifications changing because the operating system defined 
the interface. 



The operating system was developed independently using a 
PC-based development board supplied by Intel. When hard- 
ware became av ailable, the operating system was fully de- 
bugged and ready to install. The operating system is written 
in assembly language, translated from code that runs on the 
HP 9000 Series 300 workstations. This was another major 
subsystem for which we leveraged the design. The benefit of 
the operating system running on both the host and the target 
is obvious; the underlying code has no knowledge of its 
operating environment. 

Firmware Summary 

The development process of the DesignJet firmware was 
unlike any other project at the San Diego Division. Code was 
developed in a largely hardware-independent fashion. We 
strove to eliminate system timing problems through the use 
of a formal operating system. This had the additional benefit 
of defining a strict, stable interface between processes. The 
user interfaces of the plotter were developed by experts 
separate from the firmware design team. Debugging was ac- 
complished using cdb on the host and gdb960 on the target. 
These debuggers provided source-level interfaces that 
greatly enhanced the engineers' productivity. The language 
subsystem consisted of a reusable code base, and the vec- 
tor-to-raster converter subsystem we produced will be re- 
used in future products. We believe that our development 
methodology was a key factor in meeting our project's goals. 

Conclusion 

The DesignJet plotter electronics provide a high-performance 
raster plotting system at a very aggressive price. The distribu- 
tion and selection of ASICs and processors enabled us to de- 
sign a robust, flexible, and cost-effective system. Tltis design 
not only meets current customer needs, but contains the 
features necessary for leverage into future raster products. 
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Pen Alignment in a Two-Pen, 
Large-Format, Inkjet Drafting Plotter 



Misalignments are found by using a quad photodiode sensor to measure 
test patterns printed on the media. Scan-direction errors are corrected by 
timing adjustments. Media-direction errors are corrected algorithmically 
and mechanically. 

by Robert D. Haselby 



Print quality limitations of I hernial inkjel primers arise from 
several factors. These may include writing system resolution, 
pen-to-pen alignment in multiple-cartridge printers, and man- 
ufacturing tolerances in pen and carriage mounting systems. 

Also contributing to print quality problems are variations in 
inkjet drop velocity. The uncertainty of drop velocity makes 
il difficult lo correct for print quality errors when printing in 
a bidirectional mode with either single-cartridge or multiple- 
cartridge printers. Since the drop must travel a finite distance 
before striking t he media, the lateral placement of the result- 
ing drop on the media depends upon carriage speed, nozzle 
height, and drop velocity. These factors are repeatable 
enough so that unidirectional printing results in acceptable 
print quality with single-pen printers. Bidirectional printing 
of text is acceptable if the row of text is printed completely 
in one scan. This is because there is separation between 
rows of text and misalignments are not noticeable as long as 
each row of text is printed in a single swath direction. 

For throughput considerations, the I IP DesignJet plotter 
was designed with two IIP DeskJet printer multiple-nozzle 
pens and requires bidirectional printing of fully populated 
graphic data. Mechanical tolerance studies quickly revealed 
the necessity of an alignment scheme for the two DesignJet 
pens. Alignments in both the swath scan (carriage motion) 
direction and the media advance direction are required. 

We determined that one-time factory alignment would not 
be sufficient, since we have no control over pen mechanical 
tolerances and the tolerances just in installing the pen in the 
carriage exceed our print quality goal. We considered hav ing 
the customer adjust the pen alignment manually, but the 
time and customer interaction required and the subjectivity 
of a manual alignment procedure made this alternative un- 
acceptable. It seemed that only an automated system of 
alignment initialed automatically whenever a pen is changed 
would be acceptable to the average customer. 

Automatic Alignment System 

The automatic alignment system for the HP DesignJet plotter 
is based on the following principal steps: 

• Printing a test pattern on the media that is sensitive to some 
error mechanism 

> Measuring the test pattern with a carriage-mounted sensor 

• Applying a correction calculated from the measured error. 



The correct ion is applied by changes in l iming for scan- 
direction vertical errors or by physically moving one car- 
tridge relative to the other lo correct errors in horizontal 
swath banding. 

An optical sensor with high accuracy is required for this 
technique. Printing errors are noticeable if they are larger 
than a \isibie threshold, which was determined by visual 
print quality studies. Automatic correction of these errors 
requires a measurement system that is capable of measuring 
less than about one third of the visual threshold. 

A design goal was to make the alignment scheme as inex- 
pensive as possible. This ruled out a high-accuracy, high- 
resolution scan encoder scheme with a single detector such 
as a bar-code sensor. Instead, the accuracy and resolution 
had to be in the sensor. This allows the distance in the scan 
direction to be measured between two lines, which are 
printed in a test pattern during normal operation. The method 
requires that the carriage be positioned so that, the test pat- 
tern is within the maximum sensing range of the sensor. Thus 
the maximum range must be larger than the repeatability of 
the carriage scan-axis positioning system. 

The test pattern for the scan-axis calibration is a line drawn 
with both print cart ridges in both scan directions. Ideally 
this forms a continuous vertical line with no discontinuities 
visible. The test pattern vertical line is measured relative to 
the sensor without moving the carriage. This is done by mov- 
ing the media under the sensor while the carriage remains 
stationary. Bach area of interest on the test pattern vertical 
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line is measured by moving the media until the area of inter- 
est is under the sensor. Several sensing schemes were con- 
sidered before settling on this solution to the alignment 
problem. 

Quad Sensor 

A quad photodiode array is used as the sensor with illumina- 
tion from a diffuse light-emitting diode. A simple two-lens 
optical system images the test pattern onto the quad photo- 
diode. Fig. 1 shows how the quad photodiode is used to 
measure the position of lines imaged upon it. 

For detecting line displacements in a single direction, a dual 
photodetector would be sufficient. However, we were inter- 
ested in both horizontal and vertical sensing. A quad photo- 
diode allows the orientation to be controlled electronically. 
Fig. 1 shows two channels of analog signals that are con- 
verted to digital information in an analog-to-digital converter 
(ADC). Each channel is generated by taking the difference 
of two diagonally opposed elements of the quad photodiode. 
By arithmetic addition and subtraction of these two signals. 
(A-D) and ( B-C ), the sensor can be used as either a vertical 
or a horizontal different ial sensor 

(A-D) - (B-C) = (A+C) - (B+D) 

(A-D) + (B-C) = (A+B) - (C+D). 

The first equation above shows that subtracting the two 
converted analog signals gives a differential detector that is 
essentially like a dual photodiode with one element being 
segment A and segment G and the other element being seg- 
ment B and segment I). This is a dual differentia] detector 
that is sensitive to the horizontal position of the images of a 
line in the vertical direction as shown in Fig. 1. li the whole 
quad is illuminated uniformly except for the image of the 
line, Fig. 2 shows the output after subtraction that results 
from horizontally scanning a vertical line image through the 
quad photodiode array. A similar cum- would result from 
scanning a horizontal line image through the quad sensor 
vert ically while looking at. the sum of the ADC channel 
outputs (second equation above). 

Error Correction in the Scan Direction 

The vertical sensor center region is calibrated each time the 
alignment process starts. The short-term stability of the sen- 
sor is sufficient to allow calibrating it only once for the entire 
alignment process. Calibration is automatically accomplished 
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Fig. 3. Measurements for error correction in the scan direction. 

by first printing a vertical line with one Inkjet pen in a uni- 
directional prim mode. Each swath prints a vertical line 
approximately 0.015 inch wide and steps over one dot col- 
umn for each swath printed. This is repeated 2G times to 
generate the sensor calibration pattern. The media is then 
rewound so that the carriage-mounted sensor is over the 
nominal center of the slightly diagonal vertical line. The line 
is scanned across the sensor in the horizontal direction by 
advancing the media one swath for each column position 
and recording the resultant signals from the sensor. If these 
results are plotted against I he swath advance a curve like 
that shown in Fig. 2 will result. 

This data is placed in an array and processed to find the 
linear region and the slope of the linear region in counts per 
resolution element. A resolution element is defined as the 
horizontal distance between adjacent dots; for 300-dpi reso- 
lution, a resolution element is 1/300 inch. The linear center 
region is found by crosscorrelating the data array with a 
template that looks like the center portion of the ideal sen- 
sor curve. Once the peak of the crosscorrelation function is 
found, the center point and several points on either side of 
the center point are fit using linear regression in find the 
slope of the sensor curve. This slope is then used to mea- 
sure the difference of all other line segments used in the 
horizontal calibration of the carriage alignment. Limitations 
on this process are mainly because of differences in line 
width and contrast ratio, which arc caused by tlrop volume 
differences between print cartridges and different directions 
of printing. 

Fig. :i depicts a vertical test line drawn with two pens. A line 
is first printed in a left -to-right scan direction. This is fol- 
lowed by a swath advance, and then another vertical line is 
printed in the right-to-left scan direction. Fig. 3 shows the 
resulting error that would be measured on each segment of 
the "vertical" line. These measured errors are used lo calcu- 
late the drop tiring delays for each inkjet pen for each prim 
direction so that the resulting test line will be conlinuous, 
wilh no discontinuities between either print cartridges or 
swaths. The method of calculating these delays attempts lo 
drive each line segment lo some average position, which is 
determined by averaging the individual errors. The correc- 
tion delay (or advance) for each pen is calculated by taking 
the difference between the measurement for that pen and 
the average. This is the basic scheme for all corrections in 
the swath direction. 



fig. 2. Response of the difference between ihi' two quad sensor 
outputs iii the position of a vertical lino. 
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The actual process is somewhat mora complex. Each inkjet 

pen is divided into two primitives: an upper primitive 
(nozzles 26-50) and a lower primitive ( nozzles 1-25). Rota- 
tional errors can be corrected In dividing each cartridge 
into two primitives arid measuring and calculating delays (bl- 
each. Thus the actual system uses eight line segments for 
final correction instead of the four shown in Fig. 3. To mini- 
mize the effects of measurement noise, several lines are 
measured and the results averaged. Also, the sensor is af- 
fected by nonuniformily of the media. To correct for this, a 
background measurement is taken and saved before printing 
the test pattern. This background data is then subtracted 
from the differences measured for the test pattern. 

Error Correction in the Media Direction 

Pen-to-pen vertical separation errors are corrected algorith- 
mic-ally and mechanically, since in this direction, the car- 
tridges are related mechanically and not by timing. By using 
IS of the 50 nozzles on each pen and adjusting which 18 to 
use on each tail ridge, corrections can be made to the near- 
est half nozzle. However, this alone is not accurate enough 



Endplate 



Adjustable 
Cam 




Adjuslable 
Cartidge 



Stepper Motor Used to Actuate 
the Retractable Cam Slop 

Fig. 4. Print cartridge alignment mechanism for error correction in 
the media direction. 



Fixed DeskJet 
Pen (#2) 

• SO 

• 4 

• 3 



Misalignment 
Measurement 



Scan Direction 



• 50 

• 49 

• 48 

• 47 

• 46 

• 2 

• 1 



Adjustable 
DeskJet Pen 



Fig. 5. Measurement for error correction in the media direction 

to meet the print quality specification. Therefore, a second, 
mechanical means of vert ical pen alignment is necessary. 

The need for automatic mechanical adjustment of the rela- 
tive overlap distance between the two DeskJet pens on the 
DesignJet carriage was evident early in the project. Ideally, 
it was desired that the mechanism not require additional 
expensive components for actuation. These requirements 
are met by a carriage with a movable cam that can be actu- 
ated with the motion of the carriage against a retractable 
cam stop (Fig. 4 ). The cam stop is actuated by means of a 
linkage from the stepper motor that controls the pen nozzle 
wiper blade. The carnage cam is designed so that about 
5 cm Of carriage motion is required to adjust the pen-to-pen 
spacing by about three nozzles. This motion, along with the 
algorithmic selection of appropriate nozzles on each pen, 
allows Ihi' DesignJet plotter to correct for up to ±4 nozzles 
of manufacturing tolerance. 

The resolution of the media drive axis of the DesignJet print 
mechanism is nominally 12.500 counts per inch. The gearing 
is set up so that, nominally, the worm gear rotates two revo- 
lutions for each swath of media advance. This significantly 
reduces cyclical gear errors, since the gear errors have a 
periodicity that corresponds to one rotation of the worm 
gear. The high resolution and high repeatability of the media 
axis controller allow an alternative error measurement 
scheme to be applied to the media axis. 

To measure errors in the media axis direction, two horizon- 
tal, Short, nonoverlapping lines are drawn on the media, as 
shown in Fig. 5. The fixed inkjet pen (#2 in Fig. 5) draws a 
horizontal line w ith nozzle 1. The adjustable inkjet pen (#1 
in Fig. 5) draws a horizontal line with nozzle 50. These lines 
are long enough so that scan-direction positioning of the 
carriage is not critical. This pall em is repealed several times 
with a one-nozzle advance between each swath. This gives a 
wider line and a larger signal when these lines arc later 
scanned. The media is then rewound and the carriage posi- 
tioned so that the sensor is scanned through the line drawn 
by nozzle 1 of cartridge #2. The rewind distance is large 
enough so that an array of values can be stored that con- 
tains the entire sensor response, which i> like that shown in 
Fig. 2. The resultant data array is then processed by corrcla- 
lion and linear regression to solve for the center of the sen- 
sor. The media advance distance used for the data scan is 
one nozzle pitch (0. 00333 inch). This allows the units of the 
independent variable in the linear regression to be nozzles. 
The slope of the best-fit linear line through the center of t he 
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seasor response is used to solve for ihe nozzle and fraction 
of a nozzle where Ihe linear line crosses the mean of the 
data array. This process is repeated for the line from nozzle 
50 of inkjet pen #1. The difference between the measure- 
ments of nozzle 1 of cartridge #2 and nozzle 50 of cartridge 
#1 is used to calculate how much to adjust Ihe pen-to-pen 
spacing on ihe carriage. The adjustment value is used in an 
algorithm thai decides which 48 nozzles to use on each ink- 
jet pen. The adjustment remainder is used to calculate the 
final position of the adjustable carriage ram. After this cal- 
culation, the carriage and the retractable cam stop are used 
lo position the cant to correct the remaining error. 
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DesignJet Plotter Chassis Design: A 
Concurrent Engineering Challenge 



Instead of the expensive prestraightened slider rods used in previous 
designs to form the guideway for the pen carriage, the DesignJet chassis 
uses rods that are straightened during assembly and held in place by a 
low-cost rigid structure. The chassis components, assembly process, and 
assembly tooling had to be developed concurrently. 

by Timothy A. Longust 



Like an automobile, the IIP DesignJet large-format drafting 
plotter has a chassis, which serves as the foundation to which 
all of the other pans are attached. The DesigaJet chassis 
also provides a precision guideway for the pen carriage to 
move back and forth over the media. 

The DesignJet chassis is nigged and made of low-cost com- 
ponents, yet it is very precise. The concept of integrating 
ntggedness and precision is an approach that departs from 
previous chassis solutions. Instead of purchasing precision 
components and assembling them in a relatively random 
manner, this approach uses nonprecision components and 
assembles them in a precise, systematic manner. 

The DesignJet chassis concept became a reality as a result 
of a significant engineering effort that involved concurrent 




iterations of component design, assembly tool design, and 
assembly process development. 

System Requirements 

The design of the chassis was largely driven by the require- 
ment for good print quality. The two I IP DeskJet pens that 
the DesignJet plotter uses require a very consistent pen 
height above the media to achieve good print quality. The 
guideway for the pen carriage needs to be straight or true 
across a 36-inch span. It is expected to remain true even 
when subjected to external vibrations. It is not allowed to 
oscillate, thereby disturbing the pen heights. 

The chassis also needs to be very rigid since ii is the back- 
bone of the entire product, and it needs to be rugged to 
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withstand shook loads and to be immune to vibration and 
thermal cycling. These characteristics are required to be 
sustained throughout the life of the product and to be 
achieved at minimum cost. 

Design Concept 

Fig. 1 shows the final DesignJet chassis configuration. H 
uses two slider roils to form the precision guideway for the 
pen carriage. The hefty beam and two endplates form a rigid 
structure to serve as the backbone for the product Several 
support brackets are used to connect the rods to the struc- 
ture. Each of these components is assembled using screws. 

Previous chassis concepts use expensive prestraighteneri 
slider rods for the guideway and other expensive structural 
components to mount them. The DesignJet plotter chassis 
concept uses nonprestraightened slider rods for the guide- 
way and a low-cost structure that simply holds the slider 
rods straight. 

In the DesignJet plotter the straight guideway is achiev ed by 
deforming the long rods into a straight position, building and 
connecting a rigid structure onto the rods, and then releas- 
ing the rods. Although the rods want to spring back to their 
original free-state condition of being bowed and/or twisted, 
they are held tightly in place by the rigid structure. Roils 
that arc bowed as much as 0.020 inch initially can be held 
straight to within 0.006 inch once assembled. 

This concept represents a significant Improvement in per- 
formance and cost over previous chassis concepts. It 
achieves twice the guideway straightness of any previous 
solution. It also represents a significant cost savings in the 
manufacturing of the components. 

The challenge of t he DesignJet plotter chassis concept was 
t o derive a system of components that could securely hold 
the slider roils at the lowest possible cost. This system has 
to withstand the mechanical loads caused by the strain in 
the slider rods as well as the loads from shock. The system 
of support brackets and the rigid structure, serve this pur- 
pose. However, assembly of these components is not 

straightforward. 

Karly in the development it was discovered thai there are 
Considerable interactions between the components as they 
are screwed together. The interactions depend on how the 
individual components are attached to each other and the 
order in which they are assembled. In several cases individ- 
ual components ad together as groups to behave differently 
than predicted. 

Because of these complex interactions of the components 
within the chassis, the assembly process and assembly tool- 
ing became as critically important as the component designs. 
All three areas required simultaneous development. This 
concurrent engineering effort is illustrated in Fig. 2. 

Component Design 

The mounting of the slider rods was carefully studied. Hav- 
ing intermediate supports allowed the diameter of the rods 
to be significantly reduced. Without the two center supports 
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Fig. 2. The DesignJet c hassis development process required concur- 
rent component design, process development, and assembly tooling 
design. 

each rod would have had to be approximately four inches in 
solid diameter to meet the straightness and vibration re- 
quirements. Of course, some equivalent tubular cross sec- 
tion of the rods could have been used, but not without con- 
siderable cost. Intermediate supports seemed to be a good 
trade-off to minimize slider rod material and weight and add 
considerable rigidity to the rods, making the entire chassis 
assembly less susceptible to external vibrations. 

The design of the support brackets was rigorously analyzed 
to find the lowest-cost method of rigidly holding the slider 
rods in all directions. It was believed that by taking advan- 
tage of geometry, sheet metal could be used for all of the 
support brackets. Normally, sheet metal is considered very 
weak for structural applications because it is so thin. How- 
ever, all of the sheet-metal brackets in the DesignJet chassis 
are designed to take mechanical advantage of the slendcr- 
ness ratios of sectional geometries, that is, they are rigid in 
some directions while being flexible in others. Some of the 
brackets are made more rigid by forming flanges to stiffen 
sections. Some brackets are made more flexible by adding 
relatively large open areas to allow the bracket to twist or 
flatten as it is assembled. All of the support brackets ulti- 
mately work together as a system to provide the overall 
cost -effective solution for supporting the rods. 

A summary of the individual components is shown in Fig. 
This chart shows each component, the primary lunclmn il 
serves, the manufacturing process used to make it. and the 
advantages of the selected manufacturing process. A con- 
certed effort was made to match the design requirements to 
the manufacturing process to provide a cost-efficient solution 
for each component. 

For performance reasons the slider rods are made of plated 
steel. For cost reasons, the beam is made of aluminum. Since 
these components are made of dissimilar materials and both 
span the 36 inches between the endplates, there is a I hernial 
expansion issue that needed to be resolved. In the final solu- 
tion, "legs" were added within the endplates beneath the 
slider rod mounts. These legs flex clastieally under the ther- 
mal loads that develop alter a temperature change, without 
affecting the overall strength of the chassis. This thermal 
expansion design feature had negligible effect on the cost of 

the endplates. 
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Fig. 3. DesignJet plotter chassis components, (unctions, and 
manufacturing; processes. 

Process Development 

The initial goal of process development was to develop a 
basic understanding of how to achieve the performance 
goals. Later, full characterization of the chassis assembly 
would be done under dynamic and environmental conditions. 

Development of an assembly process began after a proto- 
type assembly tool was created. Each componenl was stud- 
ied individually to determine whether it performed in the 
desired manner. Interfaces between components were moni- 
tored to determine whether adequate friction developed lo 
prevent components from slipping relative lo each other. 
However, continued testing showed that the way in which 
the components are fixtured during assembly affects Hie 
resullanl friction between interfaces after assembly. Issues 
like this, along with complex component geometries, made 
continued theoretical modeling difficult Empirical testing 
was required. 

Empirical lesling included many tests using actual compo- 
nent materials and geometries. After careful studies, consid- 
erable insight was gained 10 discover which components 
and interfaces were most significant to overall performance. 
Particular groups of these components were tested separately 
from the assembly. Forces and deflections (stiffnesses) 
were measured lo optimize each group's performance. After 
achieving a fundamental understanding of the chassis assem- 
bly in a static situation, process development progressed to 
dynamic conditions. 

In shock, components within the rigid structure slipped rela- 
tive fo each other. Fastener lightening torques were in- 
creased to gain more clamp load at many interfaces. How- 
ever, in some applicafions. Ihe maximum recommended 
loads for fasteners were found to be Insufficient Instead of 
increasing the size of the fasteners, if was found to be more 
cost-effective to pretap some of f he holes instead of allow- 
ing them to be self-tapped by the fasteners. By reducing the 
drive load required to seat the fasteners, more clamp load 
became available lo prevent relative component slippage. 

To prevent component slippage furl her, il was believed that 
additional fasteners between the major components of the 
chassis assembly would be better. However, after testing, 
this idea proved to weaken the shock resistance of the as- 
sembly. The additional fasteners reduced the flexibility 
within ihe chassis assembly and thereby transmitted shock 



loads to more sensitive areas. The final soluiion uses a mini- 
mum number of fasteners lo optimize flexibility and 
strength. 

Assembly Tooling Design 

Specialized assembly tooling is required to bend and hold 
the rods in a nearly perfectly straight position and allow the 
rigid structure to be bnill around I hem. This tooling is re- 
quired to hold each of Ihe components in its proper position 
and allow access for fasteners and driving tools. 

The assembly tooling uses a programmable sequencer fhal 
precisely Controls the order in which components are 
loaded, Ihe order in which Ihe fasteners are lightened, and 
the lightening torques that the fasteners receive. Deviations 
in the assembly sequence are minimized. 

Other important design parameters for the assembly tooling 
include operator friendliness, crgonomic considerations, 
and assembly lime. 

Since each chassis is assembled using the specialized as- 
sembly tooling, each .assembly is considered factory cali- 
brated. This implies that Ihe chassis assembly is not service- 
able by service personnel or the customer. Tamper-proof 
recesses in Ihe heads of all machine screws are used to serve 
as a reminder I hat these screws should never be loosened or 
removed outside the factory. This wits a carefully monitored 
aspect of the design. 

The Concurrent Challenge 

With component design, process development, and assembly 
tooling design occurring simultaneously, the entire develop- 
ment effort was very challenging. Interrelationships between 
two areas frequently caused ripple effects in the third. 

Early testing of the assembly process showed major prob- 
lems. For example, accessibility of the fasteners and their 
driving tools into t he necessary locations of the assembly 
forced significant design changes in the components and 
assembly tool. 

Providing locating features and clamping areas for repeat- 
able component loading into the assembly tool also added 
complexity to both the components and the assembly tool. 
These features were iterated several limes. 

Conversely, limitations of assembly tool and operator ergo- 
nomics forced many modifications to the assembly process. 

Later testing demonstrated that small changes in the assem- 
bly order or the clamping order great ly affected Ihe finished 
chassis assembly's overall performance. Assembly order 
was iterated many times to optimize performance. 

To cope with the volatile atmosphere of three moving tar- 
gets coupled together, several techniques were used to 
make this development effort a success. 

The first technique was to adopt a philosophy of maximizing 
design flexibility from the very beginning of the develop- 
ment. This philosophy translated into an attempt to limit 
each component to serving a single function. It was believed 
that single-purpose functionality would make design itera- 
tions somewhat easier to predict than they would be if the 
functions of components were allowed to be consolidated. 
Overall, this philosophy proved extremely valuable. 
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DesignJet Plotter End Covers Produced 
by Coinjection 

Industrial design objectives combined with physical constraints made i! a difficult 
task to manufacture the end covers for the DesignJet plotter The deep-cored 
sarts with no-draft outside surfaces made conventional plastic injection molding 
impractical The entrre weight of the DesignJet plotter is applied to the end covers 
when a customer lifts the instrument The structural integrity required to make this 
possible, along with the need for low cost negated the use of painted metal 
parts These design requirements indicated that the coinjection process would 
best meet our needs 

The coiniection process can be described as a sandwich of conventional cosmetic 
thermoplastic skin with a structural foamed plastic core For the DesignJet end 
covers, a polycarbonate/ABS blended material is used for the skin This same 
material with a foaming agent added is used for the core Both materials are 
injected sequentially on a two-barrel injection press through a proprietary nozzle 
A controlled volume of skin material is injected followed by a controlled volume of 
foamed core material As the skin is propelled by the core material, it adheres to 
the cool mold surfaces, allowing the core material to occupy and flow through the 
middle Tins requires a minimum wall thickness of 6 mm 

Normally, a wall thickness of this size in a conventional plastic injected part would 
result in cosmetically unacceptable sink marks on the surface of the part In the 
coinjection process, the foam additive in the core material expands in the mold 
This action provides internal pressure to pack the thermoplastic skin material 
against the mold surfaces and prevent sink marks Gate location on the part is 
also important to minimize blush and flow marks. Mold flow analysis techniques 
were used to determine gate locations and flow patterns for proper mold design. 

The coinjection process provides a cosmetically acceptable pan with no secondary 
painting required. The sandwich structure is rigid and impact-resistant. All second- 
ary processes associated with conventional injection molding, such as ultrasonic 
insertion of hardware, are applicable to these comjected pans. Although more 
plastic material is used than in conventional injection molding, the cost savings 
over painted metal pans is substantial. 

In addition to these advantages, coiniection has afforded the DesignJet plotter the 
opportunity to use recycled resin in the structural foam core. 



The second technique was to involve experts early in the 
development. Experts in manufacturing helped select the 
best processes for the components. Expert tool designers 
were involved very early and agreed to the goals and ex- 
pectations of the assembly tooling. Expert production oper- 
ators were involved early and built many assemblies them- 
selves to communicate their sensitivities to the assembly 
process and tool design groups. Having experts readily avail- 
able facilitated effective decision making. 

The third technique was to avoid making several changes at 
once. Invesligations moved slowly and methodically from 
one area to another, resolving one issue at a time. The ex- 
perts were kept informed and agreed to the trade-offs, 
thereby preventing past issues from arising again. By record- 
ing dependencies of component attributes and behaviors as 
they were discovered, the process development and assem- 
bly lool design were eased. Careful documentation was im- 
portant. Many controlled experiments allowed continual 
improvements in rod straightness and shock robustness. 
This effort continued until a minimum level of performance 
was achieved. It is probable thai additional efforts could 
achieve si ill higher performance. 

Acknowledgments 

Dave Petersen was instrumental in conceptualizing the ini- 
tial design. He was extremely valuable as a team player and 
effectively adtled theoretical understaniling and mechanical 
experience. He is listed as a coinvenlor in the U.S. patent for 
the DesignJet chassis. Norm Ashley and Dennis Culver 
helped guide the initial concept away from pasl problems 
and towards a better alternative. Joe Milkovits provided 
manufacturing process knowledge and component design 
support Sieve Card and John Kurtnan provided years of tool 
design experience. Andy Tiicarico provided early production 
engineering input to the assembly tool design. 



Steven B Card 

Mechanical Engineer 

George F Nasworthy, Ji 

Development Engineer 

San Diego Technical Graphics Division 



© Copr. 1949-1998 Hewlett-Packard Co. 



December 1992 Hewlett-Packard Journal 31 



DesignJet Plotter Mechanical 
Architecture Development Process 



By investing several months in designer communication before beginning 
detailed prototype design, an architecture was developed that was 
subsequently never changed, allowing the project to reach manufacturing 
release a month early. Costs for most subsystems were lower than 
expected. 

by David M. Petersen and Chuong Ta 



The mechanical design learn for the HP DesignJet large- 
formal drafting plotter used a mechanical architecture de- 
velopment process that proved lo be very effective. The pro- 
cess emphasized designer communication early in the 
product development cycle and resulted in an architecture 
that was never changed after il was initially defined. The 
development teams for follow-on products based on the 
DesignJet architecture have found the configuration to be 
highly leveragable. 

The mechanical architecture development is the first and 
last chance to make major design approach decisions about 
product geometry without causing project schedule delay. In 
the beginning of a project, very little effort has been in- 
vested in the detailed design, so it is easy lo accommodate 
the design needs of other subsystems. However, thoroughly 
anticipating these design needs at this time is not easy. The 
DesignJet team used an architecture development process 
designed to make the needs of each stibsyslem visible so 
that they could be accommodated by other subsystems and 
competing needs could be balanced to the benefit of the 
overall product. The proc ess emphasizes communication of 
design requirements and facilitates early feedback about 
design concepts. 

History 

Historically, mechanical architecture development for one 
of HP's large-format plotters was done by only one or two 
people, ll began by assuming a design Tor servomechanisms 
to provide pen and paper movement. Ideas were collected 
about manufacturing processes that could he used to create 
a structural chassis to support the servo mechanics. 

Taking one low-cost pen plotter as an example, friction roll- 
ers and a belt-driven carriage were chosen for the paper and 
pen servo mechanics. An aluminum extrusion was selected as 
the primary structural element for the chassis, and injection- 
molded side panels, on which the servo mechanics were 



mounted, were bolted to each end of the extrusion. Once the 
basic architecture had been established, the other members 
of the mechanical leant designed their subsystems to mount 
on I his chassis. Some of these subsystems included printed 
circuit boards, cosmelic enclosures, vacuum fans for paper 
flatness, and ground rods for pen-axis guideways. 

The penalties of this approach to architectural development 
became apparent when trying to integrate the subsystems. 
The connection features for each subsystem were often not 
anticipated when the chassis structure was defined. This 
typically resulted in the addition of awkward, bulky, and 
costly parts, which were used only to mount other subsys- 
tems. Additional constraints were encountered as indepen- 
dent subsystems competed to be located near accurate 
chassis surfaces. Electrical ground paths were not inte- 
grated and unexpected structural resonances occurred The 
inject ion-molded side panels of the low-cost pen plotter, 
which were initially conceived of as flat plates, grew into 
two of the largest and most complex plastic parts that our 
division has ever built. These caused several months of 
product development schedule delay. 

The low-cost pen plotter design was a new platform for 
large-format plotters and was subsequently used as the basis 
for two other plotters. Although these products successfully 
achieved the established design goals, the mechanical archi- 
tecture approach negatively affected the development 
schedule time and the production cost of all three products. 

The primary factor that causes this type of approach is the 
urgency felt by the product development team to produce the 
first integral ed hardw are. Pressure to meet schedules can be 
extreme and the first integrated prototype is the key check- 
point showing that the product development is progressing. 
Teamwork is another significant factor. Lack of cooperation 
or working synergy between the design engineers and be- 
tween the engineers and engineering management can 
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encourage eompartmentalization of designs and responsi- 
bilities. The result can be the assignment of the entire ar- 
chitecture job to one or two individuals and a nonoptiniuin 
mechanical product architecture. 

Mechanical Design Team Selection 

The DesignJet project began with a strong belief that team- 
work can have a profound affect on development time, so a 
conscious effort was put into selecting design learn mem- 
bers who would work synergist ically with one another. De- 
signers were chosen whose technical skills and working 
strengths complemented each other to ensure a solid techni- 
cal team background. Personality compatibility was ad- 
dressed by soliciting the inputs of existing team members 
about subsequent candidates for the team. The selection 
was limited to engineers who were not entrenched in other 
projects. A specific team personality was not the goal of 
careful team selection, but rather it was aimed at creating a 
team that was balanced in technical skills and compatible in 
interpersonal relations. 

Architecture Development Process 

The DesignJet mechanical architecture development oc- 
curred during the investigation phase that preceded the de- 
tailed design of the first prototype. Fig. 1 shows four distinct 
phases within this investigation period: 
The prearchilecture phase is used to identify and resolve 
issues needed before the architecture process can begin. 
The architecture phase is the core process in which the 
integration of subsystem geometry occurs. 
The postaretutecture phase allows time for resolving difficult 
integration issues. 

The architecture convergence phase brings together the 
final vision of the integrated mechanical designs before the 
detailed hardware design of the first prototype begins. 

Prearchilecture Phase. Four mechanical engineers staffed the 
prearchilecture effort, which lasted aboul three months for 
the DesignJet plotter. The goal of this phase is to complete 
enough of the product definition and resolve the critical risk 
issues so that the architecture development will be realistic. 
The DesignJet product definition, including a use model, 
was 90% complete ;il this lime. The fundamental feasibility 
issues were already understood or investigated during this 
phase. These included plot throughput, pen type and number, 
paper cockle, and ink-to-media compatibility. 

The most significant issue studied was print quality. An ex- 
tensive tolerance analysis of print quality errors was per- 
formed. A model of the plotter mechanics and electronics as 
they would affect print quality had to be assumed. Error 
budgets were assigned to each of the subsystems. Print qual- 
ity acceptance surveys using graphic plots generated on IIP 
DeskJet printers were performed to define acceptable error 
limits. The tolerance analysis was frequently updated during 
the investigation phase as the architectural concept ma- 
tured. The error budgets became critical design goals for 
each subsystem. 

Several design solutions were defined that became the stall- 
ing pOilfts for the architecture geometry. An accurate paper 
drive system using a 2.5-inch-dianielcr elastomer-covered 
lube and pinch wheels lo move the paper was developed 
and teBtfid. Tests on this main drive roller were performed 



with paper to characterize cockle ( wet paper bubbling) and 
paper drive accuracy. The ability of vendor processes to meet 
the tightly toleranced runout specifications was studied. A 
pen alignment scheme to measure and adjust the location of 
the two pens was developed. This required inventing a system 
to measure the ink location on the paper and an adjustment 
system to reposition the pens relative to each other. 

At the end of the prearchilecture phase a complete list was 
generated of mechanical subsystems and subsystem design 
objectives. Among these subsystems were the pen carriage, 
pen carriage guideway, automatic media cutter, product 
stand, media stacking bin. product cosmetic enclosure, and 
pen service station. Also included was electrical hardware 
such as printed circuit boards, cooling fans, power switches, 
interconnect cables, various sensors, and the user interface 
front panel — these were the required subsystems identified 
by the electrical engineering team. The design objectives 
were related to both product performance and project de- 
velopment goals. Some of the product performance goals for 
the structural chassis included stiffness requirements to 
resist functional vibration and shock, an ability to tolerate 
temperature changes, and a pen carriage guideway straight- 
ness requirement that was part of the error budget from the 
print quality tolerance analysis. Some of the project develop- 
ment goals were concerned with product cost, design time, 
and design risk or the potential for unforeseen problems in a 
design choice. 

Architecture Phase. The goal of the DesignJet mechanical 
architecture development was to choose each subsystem 
design approach to best meet the needs of the overall prod- 
uct and not just I he independent needs of each subsystem. 
To achieve I his goal, the DesignJet mechanical architecture 
team met in an isolated room for three weeks to conceive 
the product architecture. The assembled engineers included 
four mechanical designers, two manufact tiring support ex- 
perts, and one mechanical lead to act as facilitator. We stayed 
at the company site to have daily access to information and 
engineering tools, but fell that isolation was necessary to 
speeil and focus the architecture phase. 

Prepared with the design goals for each subsystem, we 
picked the paper drive system as the first to develop. Archi- 
tecturally, it is the largest and most central part of the print 
mechanism. Il was also one of the high-risk designs that had 
already been prototyped in the prearchilecture phase to 
determine its performance requirements. We began by pre- 
senting I lie design goals for I he paper drive. Then various 
possible geometries were suggested, resulting in half a 
dozen alternatives. The merits and issues or each were dis- 
cussed by all the architects presenl. The engineers who 
knew the most about the paper drive defended the design 
that they favored most and gradually the process converged 
on several choices with differing advantages and issues. 
During the discussions, all architects gained a clear knowl- 
edge of the design needs of the paper drive. They each of- 
fered their own insights about the options being discussed, 
along with concerns on how a geometry might affect 
another design. These insights were absorbed by the one 
architect who would later be owner of this design. 

Next, the structural chassis was the topic of a similar pro- 
cess. Il generated a greater variety of geometries Hum the 
paper drive had. EOF this large, lightly toleranced, and 
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potentially rosily subsystem, several afternoons were spenl 
gathering eosl -versus ! olerance data about different manu- 
facturing processes. CAD sketches of the different options 
were created to allow a common conceptualization within 
the group. Rnally. several options were voted as superior. 

The pen-axis drive system was next, followed by the pen 
service station, pen alignment, electronics enclosure, stand, 
and on through the subsystems until all had gone through 
the process, resulting in one or occasionally two suggestions 
for configurations. As we progressed through the subsys- 
tems the architecture team's understanding of the impor- 
tance of interrelated design goals increased. Each architect 
began to own the design goals for all the subsystems. When 
sound ideas were presented they were reinforced by the 
team. If a marginal design idea was being pushed too hard, 
the others on the team would identify the concerns in 
enough detail to allow the advocates to rebut them or at 
least to realize the risks. As a result, each design included in 
the architecture process was subjected to significant scru- 
tiny by the entire team and the design choices made re- 
flected their combined knowledge and insight. In most 
cases, the final selection of the design approach was not 
democratic, but was left to the architect who would be re- 
sponsible fordoing the design. It is essential that the design 
owner fully support and believe that the design approach 
selection is appropriate within the context of the subsystem 
and overall product goals. 

Occasionally during the three-week architecture phase it 
was necessary to slop the meetings and perform tesls or 
gather data. Some design ideas were well-liked, but con- 
tained unknowns I hat were loo risky lo delay investigating. 

For the architecture phase, each subsystem was given lo one 
or two architects who were responsible for keeping track of 
ami sketching the various concepts. The responsible engineer 
either owned the design later or transferred it to a designer 
who joined the team late in the investigation phase. 

By the end of the architecture phase, all subsystems had 
been conceptually integrated into the plotter design. Each 
was understood in enough detail that IK) 1 Hi of the pans and 
processes were known. Simple two-dimensional assembly 
layouts were created. The process and the resulting archi- 
tecture were presented to the other involved departments 
for review, inputs and concerns were received from service 
engineering, customer assurance, marketing, industrial de- 
sign. Other Support areas, and lab management (who were 
quite relieved to see some design output). 

Postarchitecture Phase. The issues and parallel paths Identified 
in the architecture phase were the focus of the postarchitec- 
ture phase. 2.5 nionlhs was spent investigating detailed fea- 
sibility. Teslbeds were designed and testing was performed 
for user media loading, media cutler design, the Structural 
chassis, media stacking, and electronics cooling. These tests 
allowed the final selection of design approaches lo be made. 
Tow ards the end of this period the design team more than 
doubled in size as design ownership was distributed. 

Architecture Convergence Phase. Tw o final weeks Were spent 
in the isolated room to bring together the decisions on alter- 
nate design paths and complete the final vision of the me- 
chanical architecture. This time all the designers including 
the original architects were present. Engineers front the 



electrical engineering team whose inputs had been previously 
solicited were included in these meetings. The plotter sub- 
systems were all reviewed, A detailed plotter layout reflect- 
ing inputs from each designer was available. Minor issues 
were resolved and ihe detailed design of the first integrated 
prototype was ready lo begin. 

Residts 

The DesignJet mechanical architecture development pro- 
cess proved to be very successful This process reduced the 
total product development cycle time, although primarily 
after the first prototype design, build, and test cycle was 
completed. The overall product program heal the original 
schedule lo manufacturing release by one month. We never 
changed the architecture although we tried unsuccessfully 
to change some areas after the first prototype was built. In 
one instance, it was decided thai Ihe media loading design 
could be made easier to use. Some time was spent studying 
possible architecture changes to improve this area, but the 
conclusion was that Ihe original choice was still Ihe best for 
the overall system. 

Communication between the designers was excellent all 
through the development indicating an understanding of the 
needs of adjacent subsystems. Arbitration of conflicting 
design objectives by engineering management rarely was 
needed. The team members' responsiveness lo requests for 
help from other designers on difficult design areas was 
impressive. 

For most of the designs, costs were lower than expected. 
The opposite usually occurs as architectural mistakes are 
encountered that require costly redesign. We met the zero- 
week availability goal w hich allows customers to purchase 
the plotter off-the-shelf on the introduction date. During the 
production ramp-up period, the production line was opera- 
tional (S8% of the time, an improvement of 100% above the 
previous divisional best. Six months alter the start of pro- 
auction, the production support engineering stall" had been 
reduced to half the typical number. 

Our belief is that the effectiveness of this architecture pro- 
cess comes from two communication mechanisms. The com- 
mon understanding of the product requirements each archi- 
tect gains by participating in Ihe development discussions of 
each subsystem gives that person the data needed to bal- 
ance the design goals between subsystems lo the benefit of 
the whole product. Also, exposing each subsystem to design 
input and critique by all Ihe architects and others before the 
design begins prepares the designer with many insights into 
Ihe design while there is still time to react to them. 
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Improved Drawing Reliability for 
Drafting Plotters 

The SurePlot drawing system, a feature of the HP DraftMaster Plus 
drafting plotter, significantly enhances drawing reliability and unattended 
plotting ability. The system is based on a noncontact color optical line 
sensor that verifies the writing of the pens. 

by Robert W. Beauchamp, Josep Giralt Adroher, Joan Uroz, and Isidre Rosello 



The- linos drawn on an IIP Draft Master plotter. HP's high-end 
large-formal pen plotter, compare fav orably in precision and 
smoothness with those drawn by a human. The graphical 
output appears to be essentially perfect to the unaided eye. 1 
The maximum specified pen speed of 111) cm/a and the max- 
imum acceleration of 55.5 m/a- have been unsurpassed for 
over a decade. Although raster printing devices are faster, 
pen plotters are less costly and are able to satisfy the need 
for high line quality and multicolor large-format drawings. 

To a large extent the value of a drafting plotter is a function 
of how quickly it can produce drawings of adequate quality, 
thereby maximizing the daily productivity of the user. There- 
fore, we saw an opportunity to provide a superior value in 
pen plotting by reducing the time invested by the user in 
operating the HDP DraftMaster plotter. 

HP DraftMaster Plus Plotter 

The IIP DraftMaster Plus plotter incorporates three types of 
improvements that enhance the user's productivity: 
Improved reliability, high enough for unattended operation 
Improved media handling 
A friendlier user interface. 

These improvements have been made without increasing the 
cost of the product. 

The most common customer complaints about pen plotters 
have always concerned reliability, mainly pens running out 
of ink, drying out, or clogging. The SurePlot drawing system 
i s dc 'sim icd in prov ide ;i major improvement in the reliability 
of the drawing system, so that the plotter consistently gener- 
ates plots without defects, and without requiring constant or 
frequent monitoring of the pens by the user. 

Media handling is improved by roll feed, an automatic media 
cutter, and a new media tray Users can retrieve their draw- 
ings at their convenience without individually loading every 
page before plotting or unwinding a takeup spool and culling 

plots manually afterwards. 

The enhanced user interface offers a redesigned front panel 
and simplified selection of pens, sellings, and drawing qual- 
ity, Immediate action keys and direct menu access keys give 
fast access id Hie functions most commonly used. The infor- 
mal ion appears in a larger, more easily readable vacuum 
QuOrescetti display. 



This article focuses on the design of the SurePlot drawing 
system. The media handling system and the user interface 
are discussed ill the articles on pages 42 and 49, respectively. 

Common Pen Problems 

Liquid ink pens based on capillary-action ink feed are usually 
used for final-quality plots and give excellent line quality. 
However, they require careful handling by the user. Liquid 
ink pens dry out quickly if they are not capped properly 
when not in use. Also, commonly used fine-width pens, say 
0.25 mm, can experience insufficient ink flow after plotting 
a certain distance. This is because the relatively high veloc- 
ity between the pen and the page abrades the paper fibers, 
which obstruct the end of the pen capillary, ultimately re- 
sulting in the clogging of the pen so that it quits writing. This 
failure mechanism depends on multiple parameters: (he 
thickness Of the pen. the type of media used, and the plot- 
ting speed and forc e. Another common occurrence is for 
one of the pens in the mullislall carousel to run out of ink, 
becoming the cause of an unsatisfactory drawing. 

When a pen fails in any of these ways, lines that should have 
been drawn are missing, and the entire drawing has lo be 
plotted again with a considerable waste oftime. The alterna- 
tive is for the user to monitor the correct writing of the 
pens, resulting in a significant investment oftime. 

SurePlot Drawing System 

The SurePlot drawing system includes SurePlot pens, a non- 
contact color optical line sensor, a pen distance monitor, 
and extra pens, SurePlol drafting pens have ceramic tips for 
clog-free plotting and regulators to make them leak-free. 
The optical line sensor allows Hie plotter lo delect Hie most 
common pen failures: ink out, dry' out. and clogging. The pen 
distance monitor detec ts when a pen is in danger of running 
out of ink on a drawing, based on the lower bound for the 
life of the pen. Failed pens and pens nearing the end of their 
lives are automatically replaced. 

The system verifies the writing of the pen on the page by 
periodically sensing lines just placed on the page to verify 
that the print contrast Is adequate for the given pen. The 
system previously learns the print contrast for a good pen of 
each type. Ihickness, and color. If the print contrast is unsat- 
isfactory, the defective pen is replaced and the plot is either 
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restarted from the heginning or retraced from the last good 
verification, or the plotter halls to allow the user to select 
the appropriate corrective action. 

An Improvement Of 40 times in the number of drawings not 
meeting user rei|uirements has been measured for plotters 
using the SurePlot drawing system over plotters wiihout it. 
At the 90% confidence level, 998 out or 1000 drawings meet. 

user needs. 

Optical Color Line Sensor 

Thi' design objectives for the line detection sensor for the 

111' 751.1 X Series Draft Master Plus plotters were: 

Low cost. The design should not cost more than the existing 

digiii/.er. 

Small size. The line sensor package should fit into a space 
measuring 1 by 1 by 0.5 inch. 

Low weight. The moving part of the line sensor must weigh 
less than -I grants. 

1 )epth of focus. The line sensor must work over a .'t.0-mm 
range. 

Pen colors. The line sensor must detect black, blue, red. 
green, violet, aqua, and brown. We wanted yellow and 
orange but were not willing to pay the added cost to include 
them. 

Media. The sensor must work with chart paper, vellum, 
polyester, translucent media, antl tracing paper. 
Check with pen. The sensor must focus past the end of the 
pen tip but not be so low as to touch the platen when I he 
paper feeler is touching the bottom of the pen groove. This 
objective means that the pen does not have lo lie slowed 
while sensing lines. 

Lighting. The plotter must work under normal office lighting 
conditions (lights off/lights on) or in ambient light up to 
1000 lux. 



Average User Plot 

The performance of a hard copy device almost always depends on the graphic 
information being sent to it This means that an exhaustive performance test of a 
pen plotter requires that a complete test be run for every drawing in a set of draw- 
ings representing all targeted applications This amount of test effort seemed 
excessive for testing the SurePlot dtawing system for the HP DraftMaster Plus 
plotters, since we were interested in an average performance measure that would 
allow us to do summary comparisons with other products 

For this reason, we developed the average user plot, or AUP This is a single, 
standard plot that synthesizes the graphic contents of a set of drawings represent- 
ing the targeted applications at the lime it was created 119901 The AUP drastically 
reduces the test effort and allows easy comparisons between products. 

To create an AUP for pen plotters, we chose a number of user drawings represen- 
tative of state-of-the art drawing complexity and applications We then extracted 
the graphic information contained in each of the sample plots This was done m 
two ways by vectorial composition and by external shapes composition To detei- 
mine vectorial composition, drawing files were analyzed with a special parser that 
produces histograms of vector lengths, length plotted, number of pen up/down 
cycles, and other parameters. To detetmine external shapes composition, we 
measured the actual percentages of the total plotting length of each drawing that 
represented curves, lines, characters, filled areas, and so on Aftei extracting the 
graphic information in these two ways, we averaged all trie information to obtain 
the composition of the AUP We then created a unique drawing that reasonably 
matches this composition and meets our specific needs. 



The cost objective and space limitations proved formidable. 
No sensors existed that met these aggressive requirements. 
This made it necessary to develop a custom sensor. The re- 
sulting sensor meets all of the design objectives and saves 
tooling costs by using off-the-shelf parts. Assembly costs 
were kept low by considering the part assembly from the 
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Acceptable Quality Level Index 

Acceptance sampling is the set of techniques employed to estimate the quality 
level of a given set of products by measuring the quality of a limited number of 
sample products 

Since these techniques are widely applied to incoming inspection of parts to be 
used in production most of the literature specifically refers to incoming inspection 
topics ' ? 3 Nevertheless, the basic underlying concept >s applicable to any prod- 
uct in our case, we wanted to describe the overall achievable quality of the out- 
put obtained during the life of a pen plotter through knowledge of The measured 
quality of a sample of drawings obtained during a limited lime. 

Sampling plans can be divided into attribute plans and variable plans In attribute 
plans, a sample is taken from the lot and each unit is classified as good or bad In 
variable plans, a measurement of a specified quality characteristic is made on 
each unit. 

Since our quality descriptor for every drawing tested was whether it was accept- 
able, and because we couldn't make any assumption about the underlying distribu- 
tion of the data, we used the U.S. military standard MIL-STD-105D procedures for 
sampling by attributes 2 

The quality index in MIL-STD-105D is the acceptable quality level, or AQL. which 
is defined as "a nominal value expressed in terms of percent defective or defects 
per hundred units, whichever is applicable, specified for a given group of defects 
of a product " 
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slart and talking lo the vendors at each step of the design 

process. 

Mathematical Model 

A simple mathematical model was used in I he development 
ol" the line sensor. Other scanning sensors focus the emitter 
light and I he detector at the same spot and therefore are 
very sensitive to changes in height. The basic configuration 
chosen for the IIP Draft Master Plus line detection system 
achieves a large deplh of field by having the emitter illumi- 
nate a wide area and focusing only the detector at a point. 
This design removes I he sensitivity to changes in height. 

Fig. 1 shows the sensor design. The LEI) emits light with an 
intensity of I v . The intensity incident upon the media, I m , is 
directly proportional lo I v and inversely proportional to the 
si|iiare of I he distance between the LED and the media. The 
lighl I m is reflected by the media or ink into ihe optics, 
where the lens refocuses Ihe light from the media (object 
plane) lo Ihe detector (image plane) A simple relationship 
relates the image distance S„ the object distance S,„ and the 
focal length f: 

1/Sj + 1/S () = 1/f. 

The depth of focus for a single lens with a focal lenglh f is a 
maximum at S; = S (1 = 2f. This was chosen as Ihe operating 
poinl for Ihe IIP Draft Master Plus design. 

The variable used to determine whether or nol a line is pres- 
ent is the print contrast ratio, or PCR. The PGR is the ratio 
oi the drop in lighi Intensity at the detector resulting from 



light absorption by the plotted line to the intensity of the gen- 
eral white level of light reflected by the media I'sing the PCR 
to determine the presence of a line removes any dependence 
on the lighl intensity. 

Ideally, the spot size sensed by the sensor is an infinitesimal 
poinl. In reality, the detector needs some area to collect 
light. The lens also adds lo the spot size because it does nol 
perfectly focus the line onto the detector as a result of the 
aberrations of an inexpensive spherical lens. The spot grows 
even more when the lens is out of focus because of errors in 
positioning the object plane. 

The voltage output of the detector can be modeled as the 
convolution of functions representing the line. VV. the lens. L. 
and the detector, d (see Fig. 2). From a system perspective, 
the input W is a step function of width X\v (the line width). 
The system is modeled as the convolution of L and d. or 
L*d. and the output V is the voltage output of the sensor. 

The PCR can be calculated using Ihe above model: 

PCR = (V W -V mjn )/V w 

Vw = Ijii R iii 

V nl in = ln,Ri'l)(W) + I In R m (l-(l)(W)) 

C 9 Mm 

qXW) = (L* d)dX 

J-u.5X w 

PCR = d>( W)(R m - Ri)/R m , 

where R 1M and Rj are the reflectivities of the media and ink, 
respectively. 
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Fig. 2. MiitluMiiiiiii al inoili'l fur the optical line sensor. 
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This analysis demonstrates in equation form how Rj, R m , 
and Xw influence Hie PGR. For example, the absorptivity of 
the ink is not so important as 1 lie difference between R,„ and 
R|. This implies that some consideration must be given to 
the feet that media with different reflectivities will produce 
different PCRs for the same ink. For this reason a while 

sn ip lies directly beneath the sensor to boost the PGR for 

transparent media With very low reflectivities. 

As long as the sensor has not been saturated (too much 
light), the PER calculation is independent of intensity I,„. 
This independence was verified by measuring V'w and V lmn 
with the room lights on and off. 

Light Source Selection for Color Detection 

An important consideration, omitted in the above analysis, is 
the spectral characteristics of the LED, ink. media, and de- 
tector. It was tacitly assumed that the reflectivity of the ink, 
Rj. is the average reflectivity of the ink weighted over the 
spectral sensitivities of the LED and the detector: 

Ri = f Ri(/,)I v (/.)I d (/.)d/.. 

Therefore, the PCR can be maximized by minimizing R,. Be- 
cause inks are normally characterized by their aborplivity 
rather Chan their reflectivity, minimizing R; implies that the 
absorptivity Aj needs to be maximized. Thus, a light source 
should be selected that emits light at wavelengths where the 



Fig. 3. Red LED and red ink ab- 

sorbancc spectra ami dctcctni 
sciisitivil.j Inr the nowonlacl op- 
tical line sensor. The shaded area 
is a measure of the light energy 
absorbed by the ink. 

absorptivity of the ink is a maximum. Halogen light sources 
are very good candidates because of their broad emission 
spectra but are not used in this application because they get 
hot and require much more cm/rent than I.EDs. Hlue LEDs 
are good candidates to delect yellow lines but they are costly, 
emit very low-intensity light, and would have problems de- 
lecting blue lines. Red I.EDs have the highest-intensity out- 
put but they have a known problem sensing red ink. HP's 
high-intensity green LEDs were chosen for their low cost, 
low current, and emission spectrum centered in the visible 
spectrum. Green LEDs are also capable of sensing green 
lines because it is difficult to design an ink that absorbs blue 
light and red lighl bill reflects green light. Fig. -'3 shows the 
spectrum of a red LED compared lo the absorption spec- 
trum of red ink. Fig. I shows a siinihu - comparison for a 
green LED/green ink combination. The shaded area repre- 
sents the value of the above integral and is much larger for 
Ihe green LED/green ink combination. 

Figs. "> and 15 show Ihe results of sensing different colore of 
lines wild red and green I.EDs, respectively. Note Ihe low 
signal produced by a red LED over a red line, whereas the 
green I.ED gives a good signal over a green line. 

Detector 

The detector has two distinguishing characteristics not 
found in most other detectors. One is its small size (0.25 nun 



Visible Region 



Relative Scale: 


Ultra- 


Violet 


Blue Green 




Yel- 


Or- 


Red 


Infra- 


Green LED - Radiant Energy 


violet 


low 


ange 


Red 



Green Ink - Absorptivity 




Fig. 4. Green LED and green ink 
absiirhanrc spectra and detector 
sensitivity fur the iionc.ontacl op- 
tical line sensor. The shaded area 
is a measure of the lighl energy 



Wavelength (nm) absorbed by the ink. 



38 December 1992 I lewtett-Packard Journal 

©Copr. 1949-1998 Hewlett-Packard Co. 



19 



Red LED 



Line Color 
Blue Green J*Ji Rett 




Green LED 
Line Color 

Black Blue Green 




Fig. 5. Detector output for a red LEO and violet, blue, green, ami 
red lines. 
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Fig. 6. Deleclor output for a green LEO and black, blue, green, and 
red lines. 



by 0.25 mm), and the other is a two-stage amplifier inte- 
grated on the same 1C. The small detector size helps keep 
the spot size small, whic h is helpful for detecting small lines, 
while the two-stage amplifier boosts the signal before E.V1I 
can obscure il. This is important because the detector signal 
is sent across a 2-meter unshielded Ilex cable lo the proces- 
sor printed circuit board. Fig. 7 shows the detector circuit. 

Sensor Assembly 

Fig. 8 shows I he line detection sensor assembly process. All 
parts are either snapped or press-fil logelher, thus eliminat- 
ing messy, unreliable gluing processes and reducing the 
need for expensive assembly tooling. Excluding Ihe wave 
solder pass (which is done in batch mode), il takes approxi- 
mately 20 seconds lo assemble Ihe six parts that make up 
the sensor. 

Testing the SurePlot System 

Since the degree of attention needed lo obtain usable draw- 
ings and the quality of the outpul are highly dependent on 
the operating conditions, we spent some time before begin- 
ning the tests of Ihe SurePlot drawing system altempling to 
understand or model all of the possible real-life modes of 



operation and applications that users would be likely lo 
apply. 

We split the problem into three aspecls: drawing contents, 
modes of operation, and required outpul quality To keep the 
volume of tests required from becoming unreasonable, we 
synthesized in a single drawing the average graphic contents 
of a sel of customer-representative drawings. We called Ihe 
resultant drawing the average user plot, or AUP, (see page 
36). Our knowledge of pen plotter cusloniers, accumulated 
through continuing focus group sessions, customer visits, 
experience, and oilier means, allowed us to assume reason- 
able values for Ihe components of the operating modes: roll 
feed versus cut sheet, different pen/media combinalions, 
time between plots, workload, applicalions. and so on. 

Finally, we sel up the criteria to be able to evaluate the qual- 
ity of the outpul Obtained and recognize a failure silualion. 
In some scenarios users are expecting high-quality output, 
so only high-quality plots were counted as acceptable. In 
olher situations, draft-quality plots meet customer needs 
and are usable, so in t hese cases draft -quality plols as well 
as high-quality plols were counted as acceptable. In any 
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Fig. 8. Line detection sensor assembly process, (a) The detector package is captured between l he cover and tin- holder, which snap-fit 
together, (b) The LED and the detector 1C are wave suldered In I he flex cable, (c) The lens is caplured between l he cap and holder, whirl 
press-fil together, (d) The LED is snapped into Hiccup 



case, a drawing with a missing vector was considered a fail- 
ure unless it was recovered (only the IIP DraftMaster Plus 
plotter was able to do I his). 

Test Description 

To measure whether and by bow much the IIP DraftMaster 
Plus plotter is able lo produce more usable plots with less 
user attention than another pen plotter, we had both an IIP 
1 M ali Master RX plotter and an HP Draft Master KX Plus plot- 
ter plotting the AL'P eight hours a day during two weeks of 
accelerated testing in all targeted modes of operation. The 
tests consumed ten rolls of media and 20 Sure Plot and 
fiber! ip pens. 

The fairly stable and known behavior of the SurePlot pens 
allowed us to accelerate the testing. These pens were used 
in a separate plotter until most of their ink capacity had been 
spent, and were put into the HP DraftMaster Plus plotter 
near the end of their life. These pens produced all of the HP 
DraftMaster Plus failure situations recorded. This technique 
permitted us to extrapolate the results of the 270 drawings 
plotted to be equivalent to 1500 plots, which represent 150 
days of work on the basis of 10 plots per day. 

During the test, we collected data on the number and dura- 
tion of the user interventions necessary to keep the plotters 
working properly in the selected operating mode, and exam- 
ined every drawing produced by both machines to classify 
them as final plots, draft plots, or plots with missing vectors. 



Results 

Pigs. 9 and 10 show results of these tests. The qualitative 
conclusion is thai the SurePlot drawing system allows the 
HP DraftMaster Plus plotter to deliver a higher percentage 
of valid plots than its predecessor while requiring only half 
as much of the operator's time. 
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Fig. 9. Drawing reliability test results for the HP DraftMaster plot- 
ter and the HP DraftMaster Plus plotter with the SurePlot drawing 
system. 
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Fig. 10. Average user intervention times measured in the drawing 
reliability tests. 

Quantitative metrics are highly dependent on the operating 
mode. Front the user's point Of view, the question lo answer 
is "How many good drawings can I obtain from a given 
batch?" To communicate that, we looked for a statistically 
representative quality index, a single figure that would rep- 
resent the level of output quality that a customer would ex- 
perience through the operating life of the plotter. We con- 
cluded that the most appropriate index for extrapolating our 
test data to the life of the plotter was the AQL, or acceptable 
quality level, defined in a U.S. military standard as "a nomi- 
nal value expressed in terms of per cent defective specified 
for a given group of defects of a product" ( see page 37). 

The AQL results are shown in Fig. 1 1. The HP Draft Master 
Plus plotter had an AQL of 0.2 defects per 100 drawings, 
compared to an AQL of 8 for the DraftMaster. These results 
had a confidence level of 90%. This can be interpreted to 
mean that 90% of HP DraftMaster Plus plotter users, using 
recommended pens and media, will find thai 99S out of 1000 
drawings will meet their needs, compared to 92 out of 100 
drawings for the DraftMaster. This represents an improve- 
ment of -10 times in the percentage of unacceptable drawings 
over the original DraftMaster plotter. 
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Fig. 1 1. In the drawing reliability tests, the SurePlOt drawing system 
lowered the AQL (acceptable quality level) by a factor of 40. 



Summary 

The development of a noncontacl color oplical sensor thai 
verifies the writing of I he pens on the actual drawing greatly 
improves the drawing reliability of a pen plotter. The system 
operates on an extremely wide range of media, pens, and 
graphic pattern contents based on its ability to learn the 
rigid print contrast This added functionality does not add 
cost, to the product, since it replaces an existing accuracy 
calibration sensor. The system can delect errors on the actual 
traces and recover automatically. On the basis of the Al T 
and the test results, 90% of IIP DraftMaster Plus users will 
find that 998 out of 1000 drawings will meet their needs. 
This represents an improvement of 40 times in the percent- 
age of unacceptable drawings over plotters without the new 
sensor. 
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An Automatic Media Cutter for a 
Drafting Plotter 



This simple, reliable, low-cost cutter is a classical rotating and linear 
blade design. It requires no separate drive motors and does not interfere 
with normal plotting performance. To quantify its performance, cut quality 
parameters and measurement methods were defined. 

by Ventura Caamano Agrafojo, David Perez, and Josep Abella 



One (>r I lio main user needs driving the IIP DraftMaster Plus 
plotter development was to reduce the requirement for Op- 
erator attention lo tlie plotter without increasing the prod- 
uct price. It was very clear thai an automatic media cutting 
device that allowed the user to obtain drawings already cut 
to the desired size was an essential part of a set of features 
designed to satisfy this user need. With an automatic cutter, 
the cost of the product could he substantially lowered for 
some customers since the existence of a cutting device 
could eliminate the need to buy a takeup spool. 

Determining Customer Needs 

To help define the objectives for the culler development, the 
lechni(|iie called quality function deployment (QFD) was 
used lo analyze customer needs and wants. QFD helped lo 
identify the feature sel the automatic culler should have to 
satisfy customer expectations. 

The first step was to collect customer needs by means of 
focus groups. After analyzing this data, customer needs 
were classified into groups, each of which represented an 
overall customer concern such as reliability or performance. 
The next step was to define the desig.. characteristics that 
would address the customer needs. To translate cut quality 
into quantifiable terms we defined a sel of measurable pa- 
rameters. These parameters were used not only lo set cut 
quality goals but also to make comparisons with competing 
products. The definitions of these cut quality parameters 
and the procedures for measuring them are presented on 
page 10. I lesign characteristics were anal} zed based "n CBS 
lomer responses and experiments to determine their rela- 
tionships to the Customer needs. On Che basis of this analy- 
sis, we built the relationship matrix shown in Fig. 1. which 
indicates how much each design characteristic affects each 
customer need. Looking at the relationship matrix we could 
see the features that would meet the customer needs. 

One of the most important benefits from using QFD was that 
it provided the means for concurrent development across all 
functions — marketing. R&D, quality, and manufacturing. As 
result of this coordination, design changes were minimal, 
which helped us to meet our schedule. 

Mechanical System Design 

Having defined the user needs, the cut quality parameters, 
the baste design goals, the present state of technology, and 



the constraints imposed by the product itself, Ihe next step 
was lo determine the cutter design configuration thai would 
be best able to satisfy Ihe various requirements. From an 
analysis of different possible cutting systems in Ihe light of 
these requirements, il was apparent thai Ihe best solution 
was a cutter based on Ihe classical rotating and linear blade 
approach. Instead of being driven by dedicated motors, such 
a system takes advantage of ihe plotter's existing drawing 
driving system. 

A breadboard prototype with design parameter adjustment 
capabilities was built lo determine appropriate values of the 
following design parameters: 

• Rotating blade diameter (see Fig. 2). 

• Inner rotating blade cone angle (see Fig. 2). 

• Cutting speed 

• Rotating blade sharpness. 

• Side force. This is the contact force between the rotating 
blade and the linear blade, which is produced by the 
compression spring (see Fig. 3). 

• Depth of penetration. This is the amount of overlap between 
the rotating blade and the linear blade (see Fig. 2). 

• Shear angle. This is the angle between the rotating blade 
perimeter and the vertical faces of the linear blade (see 
Fig.2). 1 

Using experimental design techniques.- we were able with 
very few iterations to determine I hat all of these parameters 
were important, but only three of them were crilical. since 
cut quality was very sensitive to them. These three parame- 
ters are depth of penetration, shear angle, and rotating blade 
inner cone angle. Their acceptable v alues were measured to 
be within the following ranges: 

• Depth of penetration: >0.1 mm to 0.5 nun 

• Shear angle: >0 to 15 minutes 

• Rotating blade inner cone angle: >() to 15 minutes. 

With regard to sharpness, the totaling blade edge can be 
made blunt as long as Ihe contact surfaces between this 
blade and the linear blade are two sharp points. This is also 
good for safety and economy. 

Although media type is a very important quality parameter, 
the goal was that all the other parameters should be ad- 
justed to make cut quality as independent of media type as 
possible. For this reason, no plotter media type ranges were 
established. 
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Design Characteristics: 

I. Mean Number of Cuts Before Failure IMCBFI 

2 Cut Quality Parameters: 

2.1. Straightness 
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2.7. Edge Eflecl 

3. Cut Time 
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5. Replacement Time 

6. Media Types 
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Cutter Operation 

The culler system consists of two basic subsystem devices: 
the slitling device and the engagement and driving device 
(see Fig. 3). 

The cutter carriage stays in a rest or parking position on the 
left end ofthe pen Carriage guide arm while the pen carriage 
is being operated during plotling (see Fig. 4). When the plot 
has been completed, the paper is moved to the position 
where the cut is desired. The engagement and driving de- 
vice, a swiveling lever with a hook on the end, is activated 
by means of a voice coil, causing the pen carriage to grab 
the cutter carriage from its parking position and drive it 
along the pen carriage guide arm. The paper is cut by the 
slitting mechanism consisting of the rotating blade and the 

linear blade. 



Fig. 1. Relationship matrix fur 
the Drafl Master Plus plotter au- 
tomatic meilia culling system. 

The rotating blade contains a press-fitted O-ring that is held 
against the media by the leaf springs. Friction between the 
O-ring and the media causes the rotating blade to rotate 
while contacting the linear blade at two points (the leading 
point is the cutting point ). 

After t he cutt ing operation, the paper is moved out of the 
cutter path to avoid contact with the rotating blade. The pen 
carriage moves back to the left end of the guide ami and 
the culler carriage is disengaged, leaving it in the parking 
position. The pen carriage can then be used for a new plot. 

The voice coil thai activates the engagement and driving 
device is the same voice coil that moves the drafting pens up 
and down. 
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Pen Carriage 
Guide Arm 




Linear Blade 

Fig. 2. Do(gn parameter definitions for the cutter, which is a classi- 
cal rotating and linear blade design. 

Slitting Device 

As shown in Fig. 3, 1 he slitting device consists of the Gutter 
carriage, Ihe rotating Made assembly, and the linear blade. II 
uses the same guide ami as the pen carriage, taking advan- 
tage of an existing cavity underneath the arm. The cutting 
speed is fast enough to complete the tut before the cut 
sheet of media begins ils falling motion. 

The life of the slitting mechanism depends mainly on the 
rotating blade because the parts of (his blade are subject to 
the most wear. The blade hub is made of acetal because of 
its low friction and high wear resistance. Its wear resistance 
allows it to wiihstand the high reaction forces against the 



shaft thai are induced by Ihe compression spring. Low fric- 
tion reduces tangential forces on the media, which could 
produce buckling and nonstraighl cuts. 

The geometry of ihe rotating blade is designed to ensure high 
cut quality. The side that faces Ihe linear blade is conical so 
that the contact between the iwo blades is only at two points. 
This ensures near-perfect shearing of Ihe media rather than 
tearing. 

For durability, ihe rotating blade is made ofAISl 110 steel 
tempered to a hardness of 0-'3 Rockwell C. This material also 
offers high corrosion resistance and reasonable cost. The 
blade diameter is as large as possible to minimize the number 
of turns per cut. and ihe compression spring force is mini- 
mized to reduce wear. Since precise sharpening of the blade 
is not required, no grinding is required in its fabrication, 
which lowers its cost. 

The O-ring is important for obtaining high cut quality because 
the blade Overlap or depth of penetration depends on the 
diameter pf its torus section. It needs to adhere to the sur- 
faces on which it rolls, while avoiding tangential forces on 
Ihe media. It is made of a rubber thai meets these objectives 
and is resistant to wear caused by the media and media dust. 

The O-ring is pressed against Ihe media by the spring-loaded 
shall assembly. The friction resulting from (his force makes 
Ihe rotating blade rotate while the cutter translates. 

Engagement and Driving Mechanism 

Since the DraftMasler plotters can thaw along virtually the 
entire path of the pen carriage, it was necessary to develop 
an engagement mechanism thai would leave the way clear 
for the plotter to draw. The existing voice-coil mechanism 




Fig. 3. Exploded view of the 
automatic cutter, showing the 
t wo main parts: the slitting device 
and the engagement and driving 
device. 
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Fig. 4. The parking position of 
the cutter is at the left end of the 
pen carriage guide ann. 



thiol moves the pens tip and down was easily controllable 
and Craned out to be the best candidate lor driving the en- 
gagement mechanism. This avoids the need tor additional 
solenoids or motors. 

The upperS mm of voice-coil t ravel was not used for any 
drawing purposes. The III* ME30 three-dimensional mechan- 
ical design system was used to find the maximum possible 
angle of rotation for the rotating engagement lever given just 
'i mm of vertical drive motion. Changes in the firmware 
were made to ensure that the pen carriage does not invade 
the upper 3 mm of vertical travel during normal plotting. 

The pivot axis of the rotating engagement lever is parallel to 
the horizontal direction of motion of the pen carriage. Thus 
the inertia forces caused by acceleration of the pen carriage 
are orthogonal to the lever motion and do not induce any 
swiveling motion that could disturb the pen carriage and 
influence drawing quality. 

Reliability Testing 

The cutter carriage assembly is designed as a consumable 
part. It has to be replaced when the cut quality becomes 
unacceptable because of cutter degradation. At the begin- 
ning of the project a 5000-cut life was set as a reliability goal 
for the cutter carriage assembly. This was specified as an 
MCTR (mean cuts to replacement ) greater than 5000 cuts. 



The MCTR specifies the mean number of cuts a culler car- 
riage assembly Ls able to perform before il has to be replaced 
because of an uncorrectable failure. 

According to our user model, a Drafl Master Plus plotter will 
perform about 1)7.000 cuts during its 10-year life when used 
in an environment with a high and continuous workload. 
Consequently, the reliability goal for I he cutler system was 
set at an MCBF (mean cuts before failure) greater than 
(>7,000 cuts. The MCBF specifies the mean numbei of cuts 
the cutter system is able to make before its first failure. The 
MCBF' tloes not include failures that can be correcled by 
replacing the cutter carriage assembly. 

A nonaccelerated life lest was developed to verify the reli- 
ability of the culler system over its lifetime. This lest was 
performed on three pilot-run units with stable parts, avoid- 
ing the usual difficulties of prototype testing. The units un- 
der test CUi IIP media continuously at ambient conditions 
for two months at a rate of 1500 cuts per day per unit. To 
simulate customer use, three media types were used in the 
test in the same proportion as an average user approxi- 
mately . r >0% paper. 3096 polyester, and 20% vellum. To shorten 
the lest lime, strips of media were cut as narrow as possible. 
Such narrow strips could not fall off on their own, so a set of 
pressurized air nozzles was installed lo blow the strips out 
Of the cutler path. 
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Definitions and Measurement Procedures for Cut Quality Parameters 



Because of the nonexistence of any standard method for measuring the quality 
of a paper cut, we had to define cut quality parameters, especially those related 
to the edge finish of the cut, and develop measurement procedures for these 
parameters before we could determine what the cutter design objectives should be. 

According to the literature 1 and our experience, cut quality is usually |udged in a 
rather qualitative fashion, by visually inspecting the fibers that project from the 
cut paper edge. The less apparent these fibers are. the better the cut quality. 

Since the length and density of these fibers are very difficult tu quantify, it was 
necessary to search for other parameters that could represent cut quality as the 
user sees it and that could also serve our purposes. 

It was found that there was a very high correlation between visual cut quality, 
average edge fiber length, fiber density, and cut waviness Because cut waviness 
is reasonably easy to measure, it was selected as one of the main parameters 

Hardcopy media are paper, vellum, and polyester The cut quality parameters 
selected define both the quality of the cut edge by Itself and the quality ol the cut 
edge integrated in the media The parameters are 

• Cut edge finish- straightness, cut waviness, perpendicular waviness 

• Media geometry: parallelism, perpendicularity, accuracy, edge effect. 
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Fig. 1. Definition ot straightness S. 



Straightness, Straightness (SI is a parameter that measures how straight the 
edge of the cut is It is measured as shown in Fig. 1 . The location of the edge is 
measured at ten locations across the cut using a coordinate measuring machine 
with an optical probe. The regression line R is computed and the maximum positive 
and negative deviations from R are added to give the straightness S 

Cut Waviness. Waviness IW) is the parameter that measures the undulation of 
the cut edge along the Y axis. It is measured with a profile projector at 50x magni 
fication in five zones per cut (zone width = 8 mm) as shown in Fig. 2. In each zone, 
the distance from the deepest valley to the mean crest (where light starts being 



- — 8 mm 




Fig. 2. Measurement points for waviness W and perpendicular waviness Z 



Mean Crest 




Valley 
8 mm 

Fig. 3. Definition of waviness W 

visible through the fibers) is measured by visual estimation (Fig. 31. Waviness W is 
the maximum of the five measurements. 

Perpendicular Waviness. Perpendicular waviness (Z) is the parameter that 
measures the undulation of the cut edge along the Z axis (perpendicular to the 
media plane). It is measured visually using a manual coordinate measuring ma- 
chine with a suspended knife-edge and a magnifying glass (Fig 4) Five zones per 
cut are measured as shown In Fig. 2. For vellum, the characteristic perpendicular 
waviness is undulatory (Fig 51, in each zone, the distance between a minimum 
and an adjacent maximum is measured For paper, the characteristic perpendicular 
waviness is not undulatory (Fig. 61 and the total deformation is measured in each 
zone No perpendicular waviness is observed for polyester The perpendicular 
waviness Z is the maximum of the five measurements 

Parallelism. Parallelism |L| is the parameter that measures how nearly parallel 
are two consecutive cuts an arbitrary distance apart. It is measured as shown in 
Fig. 7 using a coordinate measuring machine with an optical probe First, the 
regression lines R1 and R2 tor the two edges are computed The parallelism L is 
the angle between Rl and R2. 

Perpendicularity. Perpendicularity (T) is the parameter that measures how per- 
pendicular two consecutive cuts are to a reference line drawn on the paper. A line 
parallel to the Y axis is used as a reference because of its stability (it depends 
only on the straightness of the guide arm, while a line at 90 degrees depends on 
the media tracking, humidity, and other factors) Perpendicularity is measured 
using a coordinate measuring machine with an optical probe The regression lines 




Fig. 4. Measurement setup for perpendicular waviness 7 
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Characteristic 
(or Vellum 




Fig. 5. Definition ol perpenmcular waviness Z for vellum 

Rl and R2 are obtained as in the parallelism measurement (see Fig 7) The per- 
pendicularity is the two angles between Rl and the reference line and between 
R2 and the reference line Since the reference line is parallel to the Y axis, the 
ideal perpendicularity is zero degrees. 

Accuracy. Accuracy IAI is the parameter that measures the difference between 
the required and actual sizes of the cut hard-copy media It is measured using a 
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fig. 7, Definitions for measurements of parallelism I perpendicularity T. accuracy A. and edge 
effect Q 

coordinate measuring machine with an optical probe One point is defined at each 
cut edge a distance of 30 mm from the uncut edge of the media at which the cut 
begins (the offset makes the accuracy measurement independent of edge effect! 
These points are PI and P2 in Fig 7 The accuracy is the difference between the 
theoretical size and the proiected distance on the X axis from PI to P2. 

Edge Effect. Edge effect 101 is the parameter that measures the curve produced 
at the beginning of the cut. It is measured using a coordinate measuring machine 
with an optical probe The starting point of each cut edge is measured These points 
are Q1 and 02 in Fig 7. The edge effect Q is the maximum of Ihe two proiected 
distances on the X axis between 0.1 and Pi and between 02 and P2 

All measurements are recorded as functions of temperature and relative humidity. 
Reference 

I Wear ol Paper Stilling Blades JnMogi International. December 1980 



Flo,. 6. Definition ol perpendicular waviness Z lor paper 



Periodically, the cutter carriage assembly, linear Made, pen 
carriage guide ann. and engagement and driving mechanism 
were visually inspected Tor wear. Oil quality degradation was 
controlled by measuring cul waviness. Culler carriage assem- 
blies were replaced with new ones when their performance 
became unacceptable. 

At Ihe end of the test each of Ihe three units had accumu- 
lated 07,000 culs. Fourteen kilometers of media had been 
cul into 200, OKI) strips. The test did not identify any major 
problem. Only two risk areas were identified and corrective 
actions were taken lo address them. 

Cutler carriage assemblies replaced after 15,000 cuts 
showed flattened O-rings and some wear on the plaslic 
frame ( ul quality began lo degrade when a cutler carriage 
assembly had performed 10.000 culs. 

Oil Ihe basis of these results it was concluded lhal the culler 
system meets Ihe MCTK and MCHF specifications. 



One of Ihe risk areas we were concerned about was the pos- 
sible degradation of Ihe coating on the pen carriage guide 
ann caused by Ihe friction of the culler carriage. This degra- 
dation could result in poor cosmetics and even corrosion 
under unfavorable environmental conditions. 

An accelerated test simulating very intensive use was devel- 
oped lo understand this failure mode. This lesl consisted of 
moving the cutter carriage assembly and pen carriage back 
and forth al high speed along a small span of the pen car- 
riage guide ami without cutting any media. The coating 
flaked off only in the areas where Ihe culler carriage assem- 
bly and the pen carriage bearing wheels had rolled. No coat- 
ing degradation appeared in Ihe areas where just one of 
them had rolled. This lesl proved I hat some deterioration of 
Ihe pen carriage guide arm cosmetics might show up al Ihe 
half-life of Ihe product when used very intensively. This led 
lo a change or culler carriage material, which completely 
eliminated Ibis problem in subsequent lesis 
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< ''inclusions 

Concurrent development and testing of this system in the 
development phases, treating it as if il were in production, 
was key to obtaining a product whose characi eristics and 
performance can satisfy user needs. 

This experience taught us that development tools such as 
QFD are very helpful if used with discretion. It is Important 
to assess the limits within which these tools can be of great 
value to the definition of the product and beyond which 
t heir contribution may he diminished or even become a drag 
on the development efforts. 

The result of this project is a cutting system with the 
following advantages: 

Independent motors and driv ing means for the cutter are 
not required, making it simpler, more reliable, and more 
economical. 

The cutting mechanism of rotating and linear blades offers 
simplicity, reliability, and low cost and provides high-quality 
cuts on different types of media with no need of any mecha- 
nism to hold the media. It also provides high durability 
because it is self-sharpening. 

The cutting system adds little weight to the pen carriage 
during its normal operation as a drafting device, allowing it 
to accelerate and stop rapidly and have all of the inherent 
advantages of a low-inertia design. Thus the same pen car- 
riage can perform both drafting and paper cutting functions 
while maintaining the original plotter performance. 
The same driving means is used for engaging and disengag- 
ing the cutter carriage and for raising and lowering the pens 
without hampering drawing performance or restricting the 
paper sizes that can be used. 



• The culling device can be retrofit to plotters manufactured 
without cutting devices. 

• The only maintenance needed consists in replacing the en- 
tire slitting device with a new one. This is done when the 
user observes a degradation In performance or when the 
plotter warns that it should be replaced (the plotter counts 
the number of cuts performed). The elastic support system, 
which keeps the slitting device in equilibrium between the 
compression and leaf springs, makes it easy (by means of a 
supplied insertion tool or even directly with the fingers) to 
separate and raise the rotating blade away from the linear 
blade to take the cutter out and install a new one. 

Acknowledgments 

The authors would like to thank Josep Maria Pujol for his 
contributions to the definition and measurement of the cut 
quality parameters, Diego Torres, Agusti Comadran, and Joan 
L'roz for their QFD work, and Felix Ruiz, Joaquim Bnigue, 
Carles Vinas, and Robert Beauchamp for their contributions 
to the cutter design. Enric Guasch was our consultant on 
experimental design techniques. Jordi Baideras managed the 
quality assurance program for the project. Steve Vanvoorhis 
was project manager. 

References 

1. Wear ttf Paper Slitting Blades, Tnhoiogy international, December 
1980. 

2. G.E.P. Box, W.G. Hunter, and J.S. Hunter. Statistics for Evper- 
inirnters: An Introduction to Design. Data Analysis, and Model 
Buildhitj. .John Wiley and Sons, 1978. 



48 December 1902 Hewlett-Packard Journal ©Copr. 1949-1998 Hewlett-Packard Co. 



Reengineering of a User Interface for 
a Drafting Plotter 



An existing user interface has been successfully reengineered and plotter 
usability enhanced by selecting, combining, and adapting software 
prototype techniques and standard software development methodologies. 

by Jordi Gonzalez, Jaume Ayats Ardite, and Carles Castellsague Pique 



HP's large-formal pen plotter family has been evolving for 
the last ten years, mainly by introducing new models that 
enhanced the functionality and performance of previous 
products. While adding more features and providing better 
performance, new models have usually required more com- 
plex and less intuitive user interaction. To facilitate the use 
of the new func tionality of the HP DraftMaster Plus plotter, 
it was decided to redesign I he plot ter's user interface. 



The reengineering of the user interface was successfully ac- 
complished by applying and adapting a combination of soft- 
ware development methodologies and prototype techniques. 
The key sleps in the evaluation, design, and development of 
the new user interface were: 

Development of a user interface software prototype for early 
evaluation and usability enhancement 
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Master Plus plotter front panel. In the filial design, four keys are reserved for menu navigation and option selection. The most frequently 
used options are assigned special keys. 
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• Detailed specification, both graphical and textual, of the 
user interface menu options, dialogues, and messages 

• Design of the user interface for easy localization (trans- 
lation) of all displayed text 

• Use of best practices for design and development: struc- 
tured analysis, Structured design, system testing, design 
walkthroughs, and code inspections. 

User Requirements 

Improvement of the UP DraftMaster user interface was iden- 
tified as a priority as a result of focus groups and customer 
surv eys. The major customer complaint was the readability 
of the LCD display, especially from different angles. The 
readability was worst under light conditions that created 
reflections and shadows. Another area for improvement was 
the basic user interaction required for menu navigation, 
function selection, and option setup. Another major limita- 
tion was the number of characters allocated to describe 
each menu option, especially for some languages, such as 
German and Spanish. 

The readability problem was easily addressed by replacing 
the LCD display with a light-emitting display technology lo 
provide good readability even in poor light conditions. 
Among the several different display technologies consid- 
ered, the best combination of cost and features was offered 
by a vacuum fluorescent display (VFD). To eliminate reflec- 
tions, the display is covered by dark plastic. The display 
window has been enlarged to facilitate readability from 
different angles and greater distances. 

To enhance the usability of the front panel, a broader under- 
standing of how users interact with a peripheral was re- 
quired. Aspects of front-panel design that had to be consid- 
ered included the layout, type of keys, number of keys, 
labeling of keys, localization, and aesthetics. L'sability aspects 
included menu selection, option setup, operation feedback, 
and others. 

Our approach to investigating and defining the most ap- 
propriate user interface was to use a software prototype 
tool to build and test different types of front panels. 

Rapid Prototyping 

The study began with the definition of numerous and highly 
diverse types of user interfaces. Key people from various 
disciplines were involved in the definition process: R&D. 
marketing, quality, product support, and industrial design. 

Softw are prototypes of the different front-panel layouts 
were generated easily and rapidly using an HP software tool 
called LogieArchitect. The prototypes allowed people to try 
different options in a very efficient manner. Very soon the 
range of options under consideration was narrowed to a 
small number. 

The use of software front-panel prototypes proved to be a 
very useful anil powerful tool with multiple adv antages. First, 
it was useful as a communication tool to describe a particu- 
lar front-panel alternative. Software prototypes were easily 
and rapidly sent back and forth between the U.S.A. and Spain 
through a computer link. Second, as a testing tool, software 
prototyping allowed the quality department to evaluate con- 
cepts early in the investigation phase. This made it possible 
to design the user interface test suite sooner. The prototype 



also served as a reference for checking the correctness of 
the user interface implementation. Third, consensus about 
which user interface to choose was achieved much sooner 
with Software prototyping; since the advantages and disad- 
vantages of each option were easy to demonstrate. Fourth, 
the prototype allowed the manual writer to stall writing 
much earlier and helped make the manual more accurate 
because the writer was able to interact with the prototype. 
Fifth, the prototype speeded development because the soft- 
ware engineers were able to reuse some of the data struc- 
tures and texts from the software prototype. Finally, the main 
advantage was that it was easy lo demonstrate the usability 
of the chosen front-panel option before development. 

Fig. 1 shows the old IIP DraftMaster front panel, two of the 
software prototype options tested, and the final front panel. 

Risk Assessment 

The initial plan was to develop the new user interface in the 
following pen plotter project The early consensus on the 
type of user interface to develop encouraged us to consider 
advancing its development. 

Before committing to Ihe development of the new user inter- 
face an estimation of the risk of adding new functionality 
late in the project was required. This risk assessment was 
based on estimates of the precision of the current project 
schedule and the defect removal effort for the project. The 
conclusion was that the project could be done on schedule, 
but there would be little margin for error. Therefore, the user 
interface development had to be done in one cycle with very 
little time for rework. 

The methods used to evaluate the precision of the schedule 
and the defect removal effort were the keys to a good risk 
assessment and are explained in more detail in the following 

sections. 

Precision of the Project Schedule. The precision of Ihe project 
schedule is a measure (hat can be derived from the project 
delay over time: the greater the project delay the less accu- 
rate the project schedule. 

Planned project progress can lie measured as the number of 
planned lest cases. A test case is a set of tests done to vali- 
date a certain unit of functionality. Actual project progress 
can be defined as the number of test cases completed up to 
a given time. The assumption is that a test case is performed 
as soon as the associated functionality is available for test- 
ing. By observing the planned test cases and the actually 
completed test cases over time one can quantify the project 
delay and the precision of the project schedule. If a test case 
finds the functionality under test to be invalid, that test case 
is considered open until the defects are fixed. Open lest 
cases are not counted as completed. This is because extra 
time is required to fix the defects, resulting in an extra delay 
in the project schedule. 

The number of planned test cases, the number of test cases 
actually performed, and the number of completed test cases 
(actual minus open) can be plotted as functions of time as 
shown in Fig. 2. Project delay can then be estimated as the 
difference in time between the date a certain percentage of 
the test cases are actually completed and the planned 
completion date. The projection of this difference over time 
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Fig. 2. Plotting the planned test cases (Plan), those actually 
executed (Actual), and those for which any defects found have been 
fixed (Actual minus Open) makes it possible to estimate the preci- 
sion of the project schedule. The estimated delay for this project 
was six weeks. 

for the DraftMaster Plus project resulted in an estimated 
delay of fi weeks. 

Rework Effort Estimation. The delect removal effort at the 
point when we were about to undertake the development of 
the new user interface was estimated as: 

Rew ork effort = ( Number of defects) x (Average time to 
fix a defect). 

The average time to fix a defect varies from person to per- 
son. It is also related to the laboratory's software develop- 
ment environment An estimate can be based on the labora- 
lory's defect history by computing the average time it has 
laken to fix a defect in the past. However, the defect track- 
ing records in the shod history' of our lab were not sufficient 
lo give an accural e average, so we took the approach of 
doing our best team estimation. This resulted in an estimate 
of 2.5 hours per defect, not including lest time. 

Several statistical lechniques are available for forecasting 
the number of defects. The One thai worked best for this 
project is based on I he defect density per test case in each 
of the system regression lesls. The same metric has been 
used as a project progress measure and as a software stabi- 
lization measure. The key benefit of this technique is that it 
gives a good estimate of the number of defects early in Ihe 
project. 

At the lime we assessed the number of defects there were 
parts of Ihe code thai were undergoing the third regression, 
while OthetS were still in Ihe first. We found thai the number 
of defects per test case and per regression was very close to 
a straight line, except for ihe first regression, where the 
straighl-linc pattern appeared after 20% of Ihe lest cases 
were executed (Fig. 3), Therefore, we established three 
conditions for estimating Ihe number of defects: 
Al least 20% of Ihe first regression is executed. 
Al least 10% of the second regression is executed. 
Al least 5 regressions are estimated lo be required, based on 
pasi project experience. 

To evaluate the total number of defects we extrapolated the 
defects lo be found in Ihe first regression at 1 00% completion, 
and the same for Ihe second. The ihe ratio of ihe numbers of 
defecls in Ihe firsl and second regressions was calculated. 
Values lor Ihe third, fourth, and fifth regressions could ihen 
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Fig. 3. Number of defects found as a function of test cases executed 
and the number of regressions. The top curve shows the total defects 
found for the project. 

be determined. The result was that at 20% execution of the 
first regression, w-e estimated !)6 defects. The actual value at 
the end of the project was 1 10 defects for the entire project. 

On the basis of the estimated 9G defects and 2.5 hours to fix 
each defect, the required rework effort was estimated to be 
1.5 engineer-months. 

I "sing these techniques we were able also to forecast the 
number of defects that would be found in the next month. 
To do litis we used our regression test plan and the straight- 
line relationship between test cases, regressions, and the 
number of defects. The results are shown in Fig. 4. 

Graphical and Textual Specification 

As a software good practice, we decided to do as much for- 
mal specification as possible of all new software functional- 
ity before Ihe design and code development phases. The 
challenge was to describe the general operation of the user 
interface formally. To achieve this objective a special graphi- 
cal syntax, combined with text, was designed as an easy and 
intuitive way to describe a generic menu-driven user inter- 
face. The main objective was lo have a working document, 
the DraftMaster Plus User Interface Internal Reference 
Specification (IRS), which would be easy to review and 
update for all the different functional areas involved in the 
user inlerface development: marketing, quality, R&D, prod- 
uct support, industrial design, and manual writing. The user 
inlerface IRS document had lo describe the sialic aspects 
of the user interface (menu hierarchy, list of options, but- 
tons, etc. ) as well as the dynamic and interactive aspects 
(dialogues, event sequences, option setups). 
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Fig. 4. Number >>f defects found versus lime. 
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The user interface physical display is one of the basic ob- 
jects used to describe the user interface. It is represented 
graphically as a rectangle with shadowed edges. A front- 
panel button is represented by drawing an outline of its real 
shape with an icon on top of ii for identification. Another 
element used in the user interface description is the screen, 
defined as the text being displayed at a particular instant in 
the user interface display. A screen is described graphically 
by a rectangular display symbol with the particular text in it. 
Particular menu options, messages, and option setup 
screens are graphically represented as screen elements. 

The description of a series of user interactions is captured 
as a dialogue. A dialogue is a sequence of events mainly 
driv en by the user — for example, the setup of an option such 
as baud rate or the number of copies. To set up a particular 
menu option, the user goes through a sequence of screens, 
making selections, setting values, and pressing buttons. Dia- 
logues are described graphically as screens connected by 
airows that define a time sequence. In a dialogue, the transi- 
tion from one screen to another can be triggered by the 
user's pressing a part icular key. This is captured graphically 
as two screens connected by arrows, with the button graph 
in between. An example of such a description from the user 
interface IKS is shown in Fig. 5. 

There is a limit on the amount of detail this graphic represen- 
tation can describe effectively. Details and complementary 
information are better described as text. 



This notation allowed an excellent review of the user inter- 
face requirements before the design phase, and facilitated a 
broad consensus among the different functional areas. The 
detailed specifications in the user interface IRS also proved 
to be very useful for system (est development. All of the 
menus and options were grouped into 25 equivalence classes 
according to the number and kind of buttons to be pressed 
to reach them, and one menu or option of each class was 
chosen and fully tested. Status and error messages were 
tested in the same way. grouping them in classes according 
to priority, and testing all possible combinations of messages 
belonging to different classes. 

Misunderstanding or incompleteness of an IRS results in 
software defects. As a result, code and tests have to be re- 
worked. In this project, the detailed specifications mini- 
mized this effect and saved a significant amount of time. 

Analysis and Design Methodology 

Working on a tight schedule, there is little time to redesign 
previous designs, 'filings have to be done right the first lime 
to minimize the time to market. With this in mind, we decided 
to use structured analysis and design practices. The struc- 
tured analysis, based on data flow diagrams. 1 allowed a team 
of software engineers to work efficiently. The goal was to 
minimize the interaction among the engineers while limiting 
the the analysis to a reasonable level of detail. 
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Default Pen Speeds: 

P R T V F Pencil 

Speed 50 60 10 30 30 60 



Fig 5. Specification example, 
with the full graphical aurl textual 
description, of the pen speed 
menu and related dialogues. The 
combination of graphics, text, 
and tallies proved to lie a simple 
and effective way to describe the 
dynamic behavior of the user in- 
terface menus ami dialogues. The 
display, with the c urrent text 
message, is represented as ,i recl- 
angle with shadowed edges. A 
user event, such as the pressing 
of a key, is represented by the 
key icon. Arrows connect the 
screen sequence to the user ac- 
tum that triggered the event. Spe- 
cial display effects, such as flash- 
ing characters or cursor position, 
are also grapliically represented. 
Lists of values for specific options 
are represented by variable names 
wit h possible values fully detailed 
in a key liox. 
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Fig. 6. Context diagram of the user interlace manager. It communi- 
cates with the plotter system through events. Events are either mes- 
sages to display, commands to execute, requests for response data, 
or notifications of plolter state changes. The user interface manager 
interacts with the outside world through buttons and sensors, a 
display for menus and messages, and an alarm beeper. 

To get a high-level pietnrp of the user interface we drew a 
context diagram and a data flow diagram. The context dia- 
gram (Fig. 6) shows the interaction of the user interface 
with file plotter system through events and with the outside 
world through sensors and buttons, the display, and an 
alarm beeper. 

The plotter system is the plotter itself and includes many 
submodules that can interact with the user interface: I/O, 
plot management, graphics engine, media handler, vector 
manager, pen handler, and so on. These modules interact 
with the user interface manager to notify or warn the user 
through messages or alarms, show the status of the plotter, 
show current menu values, set new parameters, and execute 
user interface commands. 

The data flow diagram of the user interface manager (Fig. 7) 
shows the main procedures in this module: user interface 



event manager, message handler, menu handler, and display 
manager. The user interface event manager takes care of all 
kinds of events, including plotter system, keyboard, and 
timing. 

The menu handler navigates along the menu tree and 
executes the menus at the tree leaves. It receives the menu 
events, including keyboard events ( a burton pressed by the 
user), data supplied from the plolter. timer events (like an 
inactivity timeout), and special menus triggered by the plot- 
ter from the graphics engine. The menu tree is stored in the 
menus data structure. The root is the status menu, which 
shows plotter status, such as ready, busy, paused, paper out, 
and so on. From the status menu, six main menus are avail- 
able, four of them directly available from buttons. These 
have several submenus. At the tree leaves are the menu dia- 
logues — customized menus that can show, toggle, and set 
parameters or simply trigger with or without confirmation of 
user interface commands. The user interface allows the 
nesting over the menu tree of special menus triggered from 
the graphics engine, such as the digitize menu, and several 
direct menus for easy access to the cancel, select pen, 
pause, and other often-used menus. Fig. 1 shows the user 
interface key layout. 

The message handler displays and removes messages. The 
messages come from the user interface event manager 
(from the plotter) or are internally generated by the menu 
handler ( to notify or warn the user). The messages data 
structure holds all the messages, classified by class and 
priority. Messages of different classes and priorities can be 
nested. Each class has an associated menu behavior. Infor- 
mative repetitive messages are displayed until any key is 
pressed, and are redisplayed after an inactivity timeout. Er- 
ror messages from the graphics, I/O, and other submodules 
are displayed until any key is pressed. Informative timeout 
messages are shown for a few seconds to inform or warn 
the user. User action request messages require the user to 
press the Enter button to confirm. Progress status messages 
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Fig. 7. Data flow diagram of the 
user interface manager There are 
four procedures. The user inter- 
face event manager looks for 
events from the plotter system, 
the keyboard, or the sensors. It 
also watches for timing events. 
The message handler manages 
messages coming from the plotter 
or from the user interface on a 
priority basis. The menu handler 
navigate along I lie menu tree and 
executes the menu dialogues at 
the menu leaves The display 
manager manages the display 
queue and displays the menus and 
messages on a priority basis. 
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are shown while a critical action is being performed. Critical 
error messages Indicate failures. 

The display manager controls the vacuum fluorescent dis- 
play. It manages the display queue and displays the menu 
choices. It also sets some of the display options, such as 
flashing, character set , and brightness. 

Data Structures 

The next step in the user interface design was the design of 
the data structures, which are mainly composed of menus, 
messages, and words. Static data structures were specially 
designed for easy localization lo support I he six targeted 
languages: English, French, German, Spanish, Italian, and 
Japanese. From experience, we clearly understood the need 
for an automated procedure to allow fun her refinement and 
correction of all the texts and their translations. 

Fig. 8 shows the building process for the menus and mes- 
sages data structures. Fig. 9 shows the text data structures. 
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Fig. 8. The building process for the menus and messages data Struc- 
tures: The input files are six files with the six localized menu 
screens, messages, and words. The program ctab niters and merges 
these files. The output is a C include file with Hip needed riata struc- 
tures. In the input files, there are menu screens that hold the menu 
displays used in menu iree navigation, formatted menu screens for 
the menu dialogues, message screens specifying message classes 
and priorities, and localized words for the dictionary to be formatted 
in some menu screens. 



Menus and Text Data Structures 
lp massages tp screens 




Language 



J 



Class-Priority 
Class Priority 

II 



lp dictionary 




16 Characters 



lp class priority tbl 



Fig. 9. Text data structures. Messages are uidexed by their Identifi- 
ers. Each entry contains an Index to a class priority table to select 
the appropriate behavior. Another index points to the screen table. 
For the selected language, there are two indexes to the first and 
second lines of the message forming a screen. A screen can have 
parameter fields, specified by the symbols @. S, I, S. The size of a 
parameter field is specified by repeating the same symbol. When the 
message is formatted, the parameter values or localized words from 
the dictionary' are substituted for the parameter fields. A similar 
process is applied to the menus, which are stored in the lp_menu_tree 
data structure, which has indexes to the lp_scieens structure 

In each case, the English version was built first. Some pa- 
rameters were specified, such as name, type ( menu, mes- 
sage, word), menu linkage (for menus), and message class 
and priority (for messages). There was a field for the Eng- 
lish text and another for adding the translation to a single 
language. This file was sent to the five translators, who had 
to fill in the translations field. 

We created a tool called the data structure builder for auto- 
matically building all the data structures from the six files. 
The tool produces a C include file with all the menu and 
message Structures. When changes had to be made, we just 
edited the six source files and reran the data structure 
builder again. 

The last slep in the design phase was a walkthrough to detect 
design defects. This walkthrough proved to be very useful. It 
showed some inconsistencies, but primarily it highlighted a 
major implementation issue: how to implement the menu 
dialogues. This issue is covered in the next section. 

I m plementation 

When it came to implementation, there were some Inherited 
constraints that made the reengineering of the user interface 
more difficult Most of the code had been written more than 
ten years earlier when low-level languages were more the 
rule than the exception. The software system architecture 
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was imerrupl-driven and had no operating system for task 
scheduling and dispatching. The new user interface was 
constrained to exist in this environment. The plotter system 
runs as a background process and the user interface is trig- 
gered at an interrupt level by a periodic interrupt event. The 
user interface manager and the plotter system communicate 
through queues as shown in Fig. 10. 

The plotter system was loo hard to model, so we decided 
instead to have a clear, well-specified interface to the user 
interface queues and then surgically remove the old user 
interface references and add the new ones. 

The user interface manager is scheduled through a periodic 
interrupt. It is basically a state machine with states, input 
events, and outputs. When activated, it checks for an event 
(button press, timing, or plotter) and handles the menus or 
messages depending on its state and the event. 

Anoiher limitation, because of the lack of an operating sys- 
tem, is that the dialogues (menu leaves) were designed as 
independent tasks. They are called upon entering a dialogue 
menu and they end when the user operation is completed. 
They are implemented in the user interface manager at the 
interrupt level. Therefore, we had to design a small operat- 
ing system subset just to put the menu dialogues to sleep 
when waiting lor events and wake them up at the next inter- 
rapt We supplied a local stack so the user interface man- 
ager would be better isolated from the rest of the system 
and could more freely build its own display screens. 

The last important issue was how to support the design 
team of three engineers so that I hey could work efficiently 
on the same set of modules and within the schedule con- 
straints. We succeeded thanks to a well-established software 
management control system for supporting parallel develop- 
ment. This system is based on RC'S and includes some scripts 
to better automate the generation of code releases. It also 
Supported our intensive use of code merges. The data struc- 
ture builder already mentioned made it easy to update the 
menus and messages. 

Results 

The IIP Draft Masler Plus user Interface reengineering proj- 
ect met its planned introduction date and its main project 
objectives. The number of software delects was very low 
compared to previous projects in this lab. 
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Fig. 10. Interaction between the plotter system and the user inter 
face manager. The user interface can request the plotter system to 
schedule the execution of a particular function or procedure. The 

user interface manager can also send a request for data maintained 
hy the plotter system The plotter system interacts with the user 
interface manager hy means of messages anil update events. 



The project took 0.5 months. One month was spent in selec- 
tion of the best proposal. Three months were invested in the 
definition of the IRS and the system tests — a measure of the 
amount of specification effort. The final 2.5 months were 
spent on coding and testing. 

The project complexity, measured by the amount of new C 
code written, was 15 KNCSS (thousands of noncomment 
source statements). 

The number of defects related to the front panel found be- 
fore introduction was 37. To determine the quality of the 
specification and coding activity, the defects were classified 
as specification defects ( 1:3*)), coding and design defects 
(84%). or hardware defects (3%). The specification category- 
includes such defects as misunderstandings between team 
members, side effects of specifications, incomplete specifi- 
cations, and wrong specifications. The low percentage of 
these defects is a clear improvement over previous projects, 
indicating that the specifications were clear enough that 
every team member was able to understand the expected 
product behavior. 

Defects found in new and old modified code were: 

• New code: 38% 

• Old code: 62%. 

The quantity of code written in the old assembly language 
was much smaller than the quantity of new code, proving 
again t hat the modificat ion of old patched code is much 
harder than writing brand new code. The prerelease delect 
density in the new C code was 2.5 defects/KNCSS, This is a 
significant improvement over previous experience in our 
lab. At introduction, there were no open defects in the user 
interface. 
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A Multiprocessor HP-UX Operating 
System for HP 9000 Computers 



The system supports up to four processors in the HP 9000 Model 870 
computer, significantly increasing online transaction processing (0LTP) 
performance without degrading uniprocessor performance. 

by Douglas V. Larson and Kyle A. Polychronis 



The kerne! of I lie HP-UX* operating system has been modi- 
fied (o support PA-RISC multiple-processor systems in a 
symmetrica] manner ( PA-RISC is Hewlett-Packard's reduced 
Instruction set computer architecture), in a symmetrical 
multiprocessor system, any processor can run any task — 
user or kernel — on the system. The first release of this prod- 
uct, HP-UX 8.06, supports up to four processors with the 
HP 9000 Model 870 hardware. t Although the current system 
is implemented for up to four processors, there is no funda- 
mental design limitation on the number of processors that 
can" be supported. 

The Model 870 multiprocessor HP-UX systems represent a 
significant technical milestone for HP for several reasons. 
First, the hardware, which is used by both the IIP 91)00 
Model 870 and the HP 3000 Scries 980 computer systems, is 
the first multiple-processor implement at ion of HP's PA-RISC 
architecture. Multiprocessor systems are an important tech- 
nical direction for the industry because they offer the most 
cost -effective means of improving the performance of a 
given platform. Adding a processor board to a system is an 
extremely effective way of adding power. 

Second, the Model 870 multiprocessor system raises HP-UX 
online transaction processing (OI.TP) performance to a new- 
level. In fact, at the time of the Model 870's introduction, it 
had the best performance in the industry for UNIX * -system 
computers running the TPC-A benchmark (Transaction Pro- 
cessing Performance Council Benchmark A). We had to 
solve a myriad of difficult technical problems at both the 
operating system level and the database manager level to 
achieve this performance. 

Finally, we advanced the stale of the art of mull iprocessor 
UNIX-system computers by effectively harnessing the power 
of multiple high-performance RISC processors. Previous 
UNIX-system multiprocessor machines have featured rela- 
tively low-powered microprocessors. Using a processor with 
the capacity of the Model 870 with its fast, large caches is a 
fundamentally harder multiprocessor problem; adding a 
single Model 870 processor is equivalent to adding half a 
dozen Intel 80386s, for example. 

PA-RISC Multiprocessor Hardware 

The PA-RISC architecture includes specification for multi- 
processor systems with a tightly-coupled shared main 

t After this article was written, a new multiprocessor system was released See page 58 tor 
more about HP-UX 9.0 on the HP 9000 Model 890 computer 



memory model. Each processor has its own cache (see Fig. 
1). Perhaps the most important characteristic of t he PA- 
RISC multiprocessor design for software is the automatic 
maintenance of consistency in t he system caches. Although 
cache coherency is transparent to software, the costs of 
cache coherency may be significant. Another PA-RISC multi- 
processor concept is that of a monarch processor. At 
power-up, the processors arbitrate to determine a monarch, 
which subsequently performs the boot process. 

In a Model 870 multiprocessor system, up to four Model 870 
CPU boards can be inserted into the chassis (see Fig. 2), 
w here they interface to the system memory bus (SMB). 
From the SMB, a bus converter connects to the MidBus and 
the HP CIO channel adapters for I/O cards (see Fig. 1). All 
processor clocks and the SMB clock ran asynchronously 
with respect to each other. This necessitates software ^syn- 
chronization to provide a consistent system-wide clock to 
the software. 

As mentioned above, cache consistency is maintained auto- 
matically by hardware in the PA-RISC multiprocessor archi- 
tecture. However, in the Model 870 multiprocessor system 
the overhead to maintain cache consistency is high. For ex- 
ample* a cache miss on one processor when the same cache 
line is dirty in another processor's cache results in a worst- 
case ( typically 170-cycle ) miss penalty, which is far greater 
than the typically 70-eycic penalty for a uniprocessor cache 
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miss. This condition is exacerbated when daia is shared 
between processors on a Model 870 multiprocessor system. 
The cache miss rate can go up dramatically, resulting in a 
dramatic decrease in Ihe system's throughput. Working to 
minimize cache effects has dominated the Model 870 multi- 
processor tuning effort. 

Another challenging situation was the speed of the proces- 
sor relative to the SMB memory bandwidth available in the 
Model 870 chassis. With the Model 870, we placed an ex- 
tremely powerful liliiO-vintage processor into a chassis that 
was designed in 1983. 

Implementation Strategy 

Our multiprocessor implementation of HP-UX 8.0G needed 
to meet the following requirements: 
Support symmetrical multiprocessor execution for up to 
four processors. 

Be transparent to user-level code t source and object ). 
Provide industry-leading performance running the industry 
Standard TPC-A, TPC-B, and multiprocessor SPEUmark 
benchmarks. 

Support all features of HP-UX 8.0 (except ('2 security and 
diskless clusters, which would have added significantly to 
the schedule). 

Run Ihe same kernel on uniprocessor and multiprocessor 
systems, bill have negligible overhead on uniprocessors. 

The HP-UX operating system is multitasking and supports 
running numerous processes at any one lime. In a unipro- 
cessor system, only one process is executing at any given 
moment, and the consistency of HP-UX kernel global data 
structures is ensured because processes running in the ker- 
nel are allowed either to run to completion or to run until 
they voluntarily give up Ihe processor. In eilher case, the 
global data structures are consistent at the time another 
process is scheduled, so I here is no need to use semaphores 
or Other concurrency control mechanisms thai are seen on 
Other multitasking operating systems. (The only explicit data 
st met lire protection is between Ihe kernel and interrupt 
service routines. ) 

In a multiprocessor System, however, this uniprocessor as- 
sumption is shallered. For adequate multiprocessor system 
performance, il is essential that multiple processes on differ 
enl processors execute simultaneously In the kernel in this 
multiprocessor scenario, kernel data structures are being 



updated simultaneously with unpredictable interleaving of 
updates, which inevitably leads to kernel data structure 
corruption. 

The single greatest technical problem in adapting HP-UX for 
multiprocessor operation was adding the kernel data struc- 
ture protection needed to allow simultaneous execution of 
processors in the kernel. This was achieved by adding sema- 
phore and spinlock primitives to HP-UX. and using these 
primitives to synchronize accesses to global data structures. 
Even.' module in HP-UX was affected by these changes. 

Another area of the kernel requiring significant modifica- 
tions was the scheduler. Instead of just scheduling for a 
single processor, the scheduler must now manage ihe com- 
puting resources of multiple processors. Also, low -level op- 
erating system code such as TLB miss handlers and power- 
fail recovery procedures required extensive modification for 
multiprocessor operation. 

Once the multiprocessor system was operating, a tremen- 
dous effort was required to tune the system to meet our per- 
formance objectives. In our view, the key challenge of multi- 
processor system performance is tuning the system Tor Ihe 
characteristics of the target hardware. Because of the nu- 
merous combinations of processor speeds, bus speeds, and 
cache configurations that are possible in multiprocessor 
systems, it is a virtually impossible lask to develop a multi- 
processor kernel that will perform well for everybody 
without a significant amount of tailoring. 

Prototype Refinement 

< )ur development strategy was to start with a coarsely sema- 
phored prototype multiprocessor HP-I 'X system and succes- 
sively refine it to address observed performance bottle- 
necks. For example, concurrency could be added where 
needed to relieve spinlock and semaphore contention. 

( )ur starting point was a single-semaphore system, which 
essentially emulates the uniprocessor situation by only al- 
lowing one processor in Ihe kernel at a time. This was useful 
for bringing up early multiprocessor prototype hardware, 
but has obvious performance limitations. 

Our first concurrent multiprocessor kernel involved only 
four "empire" semaphores ( file system, virtual memory, pro- 
cess management, and I/O), together with a handful of spin- 
locks. While the semaphoring here was very coarse, it pro- 
vided the basis for measurement, analysis, and furl her 
rounds of inning. 

Our lulling efforts since Ihe initial four-empire system have 
led in a significant division of ihe virtual memory empire, 
with a lesser division of the file system empire, to add more 

concurrency to the system. However, we found thai the hulk 

of our Inning cycles were devoted to reducing overhead 
resulting from cache effects on Ihe Model 870 PA-RISC 
1 1 1 1 1 1 1 i p rocessor hard ware. 

The conventional wisdom for multiprocessor systems has 
been to add as much concurrency as possible up front ( fine- 
grained semaphoring) and use this as ihe basis for Inning. 
This approach would have been disastrous on the Model 870 
multiprocessor hardware because of Ihe high cost of locking 
resulting from cache effects. This would have led to a high 
level of rework CO address Ihe real performance problems. 
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Next-Generation Multiprocessor HP-UX 

The accompanying article describes the first-generation HP-UX multiprocessor 
system, which consists of the HP-UX 8.06 operating system running on the HP 
9000 Model 870 computer hardware A new multiprocessor system, consisting of 
the HP-UX 9.0 operating system on the HP 9000 Model 890 computer hardware, 
was released after this article was written Hardware and software advances 
contribute to a substantially higher level of online transaction processing I01TP] 
performance for this new system 

The Model 890 hardware incorporates new chassis and bus designs that address 
the limitations mentioned in the accompanying article The main processor bus is 
dramatically faster and the cache coherency circuitry has been improved The 
Model 890 also uses a higher clock rate 

The operating system software has been improved through increased parallelism 
in the I/O subsystem and additional OITP performance tuning. In TPC-A bench- 
marking experiments, a more efficient client-server configuration is being used 
instead of the monolithic configuration used for the Model 870 measurements 

The result of these improvements is a TPC-A rating of 578 transactions per second 
for a four-processor HP 9000 Model 890 computer system in a client/server config- 
uration, compared to 173 transactions per second for the four-processor Model 
870 in a monolithic configuration 



Successive refinement of prototypes including adding con- 
currency where needed is I lie most pragmatic approach lo 
retrofitting an originally uniprocessor system such as HP-UX 
for multiprocessor operation. Given the complicated inter- 
actions involved with HP-UX running on a multiprocessor 
system (cache effects, semaphore contention, etc.), it was 
impossible to predict precisely what modifications were 
needed for best system performance; experimentation with 
the multiprocessor technology wits essential. 

Concurrency Control Primitives 

The hear) or concurrency control within our multiprocessor 
system is the spinloek. HP-UX kernel primitives have been 
added to obtain and release spinlocks. If a processor at- 
tempts to obtain a spinloek that is held by another proces- 
sor, it will busy-wail until the lock becomes available.t 

Spinlocks are used to control access lo data structures that 
will be held for a relatively short period of time. In such 
cases, a blocking semaphore doesn't make sense because 
the overhead of a context switch is likely to be longer than 
the time a processor will need to busy-wait for the lock. 
Spinlocks must be used during interrupt service routines, 
when context switching is impossible, Spinlocks are also at 
the heart of our blocking semaphore calls to control access 
to the semaphore data structures. 

The conventional method for supporting spinlocks is to lake 
advantage of a test-and-set instruction in the hardware. In 
PA-RISC, this is the load and clear word instruction (Idcw).t t 

t Spinlocks are at the care of HP-UX concurrency control Procedure calls to spinloek routines 
specify the lock lo Be acquired as an argument II the lock is tree, the spinloek routine acquires 
the lock and marks it as busy If the lock is already busy (that is, another process or processor 
holds the lock), the routine will busy-wait until the lock Becomes available The busy-wait is a 
program loop in which the lock is repeatedly checked until it becomes tree An important 
attribute ol a spinloek routine is that the action of checking a lock and marking it busy is 
atomic — no other process or processor can acquire a lock after its availability has been 
checked and belore it is marked busy 

ft In this paper. Idcw is used as an abbreviation to refer to the Idcws and idewx PA-RISC 
instructions 



However, because of c ache effects associated with Idcw on 
the Model 870. the cost of an Idcw Instruction is extremely 
high, and we realized a significant multiprocessor perfor- 
mance improvement (approximately 20%) by using an algo- 
rithm relying only on loads and stores for mutual exclusion. 

Blocking semaphores are used to control access to regions 
of code that are associated with a set of data structures. 
With a blocking semaphore, a processor attempting lo ac- 
quire a semaphore already held by another processor will 
put its current process to sleep and switch to another task. 
The assumption is that the expected time lo busy-wait for 
the lock will be much greater than the overhead of a process 
switch- 
There are three types of blocking semaphores: 
Alpha semaphores. These semaphores are relinquished 
when a process goes to sleep, so the data structures 
protected must be consistent whenever sleep is called. 
Beta semaphores. These semaphores are retained while a 
process sleeps. 

Synchronization semaphores, These are used to signal 
events rather than protect data structures. 

Fig. 3 shows the decision process for choosing the appropri- 
ate protection mechanism for kernel data structures. 

Race Condition and Deadlock Avoidance 

Convening a uniprocessor operating system to a multipro- 
cessor operating system adds two new classes of software 
problems: inteiprocessor race conditions and interprocessor 
deadlock conditions. Also, existing intraprocessor race and 
deadlock conditions become much more likely to occur. 

A race condition occurs whenever data that should be pro- 
tected by a lock (a spinloek or semaphore) is accessed with- 
out the appropriate lock being held. The thing that makes 
race conditions hard to notice is that almost every time code 
with race conditions is executed, it works with no problem. 
However, occasionally it will fail, and it usually fails in a 
drastic and difficult-to-diagnose way (e.g., a system crash). 

To attack the problem of race conditions we developed a 
tool that we called SDTA (semaphore data trap analysis). 
Fundamentally we gave the tool (which was built into the 
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Fig. 3. Decision process for Choosing protection mechanisms for 
kernel data structures 
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kernel as a driven a list of data structures and the corre- 
sponding locks protecting each of these structures. Then we 
used a feature of the PA-RISC architecture that allowed us 
to trap whenever one of these data structures was accessed. 
I'pon trapping. SDTA tested to see if the appropriate lock 
was held, and if not. an error message was logged. In a con- 
tinually changing development environment such as ours, 
with many people working on the code, this is a strong 
regression testing tool- 
Deadlock conditions occur whenever it is possible for each 
tif two processors to be waiting for the other processor to 
release a lock so that it can acquire it. In this state they will 
wait indefinitely for each other ( see Fig. 4 ). More compli- 
cated cases with three or more processes are also possible. 
We chose to solve this problem by instituting a simple, well- 
known deadlock av oidance algorithm. This algorithm re- 
quires that all the locks in the kernel be taken in a particular 
order. We Implemented this by giving each lock an order (an 
integer), and then enforcing the rule by testing within the 
semaphore code to ensure that whenever a semaphore was 
taken, no higher-order semaphore was already held. By en- 
forcing the acquisition of locks in lock order, I lie cycles that 
lead to deadlock can never occur. This enforcement is done 
through a series of assertions within the semaphore code. 
Assertions in the code are statements of the form: 

ASSERT|<condition that should be true>,"statement of problem"!. 

The programmer decides what condilions must always be 
true at a particular point in the code and puts the assertion 
in. If the condition is violated then an error condition is 
noted. Assertions can be turned off a! compile lime, and 
because Of their impact on performance we do not ship the 
product with the assertions turned on. Testing with the 
assertions turned on and compiled allows us to detect prob- 
lems early. Because assertions affect liming and could po- 
tentially cause other problems, we also test with assertions 
turned off. In HP-UX 8.06 there are well over 1000 assertions, 
over 200 of which are multiprocessor-specific. Different sets 
(il assertions can be turned on and offal will. 

Processor Scheduling 

In our early multiprocessor prototypes, a single run queue 
was maintained, and the highest -priority process was as- 
signed to the first processor available. This is the spirit of a 
symmetrical multiprocessor implementation: any task can 
execute on any processor. However, we soon recognized 
that cache effects made the cost of migrating a process be- 
tween processors significant. A process builds up a cache 
Context on a processor, and if the process is migrated, that 
context needs to be rebuilt completely on another proces- 
sor. The situation is worse if dirty cache lines are associated 
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with the original processor when a process migrates be- 
cause this causes the worst -case cache miss overhead when 
those lines are reaccessed by the new processor. 

To address this situation, we implemented a new design 
w ith a run queue for each processor, and we added heuris- 
tics to control the migration of processes between proces- 
sors to minimize cache effects from process migration. Con- 
trolled migration is necessary to allow load balancing, but 
processes should slay on the same processor whenever 
possible. This can l>e viewed as heuristic processor affinity. 

For certain applications, our heuristics are inadequate for 
optimally assigning processes to processors. For these 
cases, we have implemented explicit processor affinity 
with an interface to allow applications to make process-to- 
processor assignments. In our performance tuning, we have 
been able to achieve a 10%-to-20"w improvement in TPC-B 
performance by explicitly assigning processes from the 
application level through a proprietary processor affinity 
interface. 

We are noi widely promoting explicit processor affinity as 
an available feature of the product because our interface is 
nonstandard. We plan to move to a standard interface for 
processor affinity as soon as one emerges. I 'mil then, our 
proprietary interface is being documented through the field 
organization for use in customer situations where explicit 
affinity is necessary for adequate performance. The heuris- 
tic processor affinity with automatic load balancing will 
perform well for mosi workloads. 

Interrupt Handling 

All interrupts are directed to the monarch processor. If the 
monarch processor holds the I/O semaphore, or if the I/( > 
semaphore is free, then the monarch will acquire the I/O 
semaphore if necessary and handle the interrupt.. If the I/O 
semaphore is held by another processor, then the monarch 
will forward the interrupt lo the processor holding Hie I/O 
semaphore. 

This implementation is soinewhal asynuiielrical, but we 
have shown through experimentation that this is superior in 

performance to the symmetrical implementation of broad- 
casting the interrupt lo all processors and having the 
processors arbitrate lo determine who handles n 

I/O Drivers 

There are many I/O drivers in HP-UX, and significant modifi- 
cations lo all of them for mull iprocessor operation would 
have greally added lo the expense and risk of HP-UX 8.06. 
Because of Ibis, we provide uniprocessor emulation for 
drivers, This allows existing I/O drivers to be incorporated 
into the mull iprocessor system with few if any changes. 

I niproccssor eniulalion is possible because a single sema- 
phore is used for all l/< ). and spl (the call used lo raise the 
interrupt level} is supported in multiprocessor HP-UX. How- 
ever, there are performance penalties for Ibis, because all 
I/O Is Single-threaded and because spl calls in the multipro- 
cessor system are expensive because of contention for the 
underlying spinlock. ( ontention from these sources has 
been deal! with in the tuning of HP-UX 8.06 for certain 
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commonly-used I/O drivers. For example, the HP-FL disk 
driver has been broken away from the I/O semaphore to 
allow il lo run eoncurrenlly wilh oilier I/O. and we have 
reduced the spl calls where possible in other kpy drivers. 

Multiprocessor Boot Process 

Al system power-on, the monarch processor is boot- 
si rapped. IPL (initial program loader) will load HPUXBOOT on 
the monarch, and the monarch will then load the HP-UX 
kernel. When control is transferred to the kernel, the system 
is still using only the monarch processor. Kerne! initializa- 
tion is performed on I he monarch, and the last step in kernel 
initialization is to activate the other processors on the system 
and put the system into multiprocessor operation. 

Uniprocessor Overhead 

A requirement for multiprocessor HP-UX was the need for 
an extremely low multiprocessor overhead on uniprocessor 
systems. This is because the majority of HP's computer sales 
are derived from uniprocessor systems. To achieve a negligi- 
ble level of multiprocessor overhead on uniprocessor sys- 
tems, we have added special-case code for uniprocessors iti 
key places, and we "back-patch" most multiprocessor sema- 
phore primitive calls at boot lime to eliminate locking over- 
head on uniprocessor systems. In other words, the system 
automatically modifies itself at boot time lo specialize itself 
for uniprocessor or multiprocessor operation. As a measure 
of our success, HP-UX 8.06 on a Model 870 uniprocessor 
system outperforms HP-UX 8.0 on the same machine be- 
cause of negligible multiprocessor overhead on the unipro- 
cessor coupled wilh performance improvements thai improve 
both uniprocessor and multiprocessor operation. 

One consequence of our success in reducing uniprocessor 
degradation by effectively creating a uniprocessor-only sys- 
leiu al run lime is thai our multiprocessor improvement ra- 
tios over uniprocessors are reduced. The ralios would look 
much heller if our multiprocessor kernel were run unmodi- 
fied on a uniprocessor for the basis measurement, which is 
common industry practice. 

Performance 

As mentioned previously, our development approach was 
based on the successive refinement of a series of proto- 
types. This was especially necessary for Model 870 multipro- 
cessor performance tuning because the complex interac- 
tions between many hardware and software components 
resulted in unpredictable performance resulls beyond the 
current set of modifications. 

Our performance tuning was an iterative process as follows: 

1. Measure and analyze the current syslem. 

2. Propose a candidate set of modifications. 

3. Perform a quick implementation of these modifications on 
an experimental system. 

L Evaluate the performance of ihe experimental system and 
choose ihe modifications to put into the production system. 

5. Perform detailed design and review on the selected modi- 
fications and integrate them inio the main body of multi- 
processor kernel source code. 

6. Go to step I. 



Wc relied primarily on kernel profiling lo analyze system 
performance. The profiling was done while running a variety 
of industry-standard and proprietary benchmarks. Through 
the profiling, we saw where the system overhead was 
excessive. 

A change lhat we made from previous HP-UX syslem profil- 
ing is what we call time-based profiling. In Ihe past. HP-UX 
profiling was based on instruction counts, but this hides ihe 
high overhead of multiprocessor cache effects. For example, 
a load and clear word (Idcw) instruction is many times more 
costly than most other Instructions, but si ill accounts for 
only one instruction in an instruction-count profiling system. 
With lime-based profiling, the actual time spenl in routines 
is measured, including time costs for cache effects. 

The profiling output was organized according to procedure 
calls, and ordered according lo the eumulalivc time spent in 
these routines. In this way, Ihe costly routines were high- 
lighted, and we investigated them further to analyze why 
they were consuming excessive processor bandwidth and 
what steps could be taken to optimize them. 

Other lools that we used for evalualing performance in- 
cluded instrumentation thai we added lo measure sema- 
phore and spinlock contention, and measurements by 
AWAX. a proprietary tool thai supports accurate low-level 
measurements and logic analysis. 

Wc iterated through the Inning cycle approximately six 
times during multiprocessor HP-UX development. Each 
cycle look approximately eight weeks, with the first four 
weeks devoted to analyzing system performance and quickly 
prototyping a set of candidate changes, and the next four 
weeks spent doing detailed design, performing code re- 
views, and running regression tests. Careful attention to 
quality while integrating performance modifications With the 
system allowed us lo continue performance tuning well into 
the system test phase and practically up to release. 

Benchmark Performance 

Table I summarizes the performance of the HP 9000 Model 
870 multiprocessor system with one to four processors for 
the TP( ' A and SPEC Aggregate Throughpul benchmarks. 
TPC-A is an Industry-standard OLTP benchmark that rales 
systems in transactions per second, anil SPEC Aggregate 
Throughput is an industry-standard benchmark for measuring 
system throughput under an artificial workload. 



Table I 

HP 9000 Model 870 Multiprocessor Performance 

Model Model Model Model 
870/100 870/200 870/300 870/400 

TPC-A 74.5 111.2 



not 17.12 
measured 



SPEC Aggregate 
Throughput 



35.4 



67.3 



95.3 



127.7 



The multipliers for multiprocessor systems over a unipro- 
cessor base are very dependent on the system workload. 
For compute-bound processing, we observe better results. 
In fact, you can run four copies of a Spice simulation in par- 
allel on a Model 870/400 in the same time it takes to run a 
single copy. The reason for this is that on compute-bound 
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jobs such as Spice, there is no data sharing between jobs 
and little time is spent in the kernel, so there is little multi- 
processor contention for resources and no appreciable 
cache coherency thrashing. 

For this reason, it is no surjiri.se that the SPEC" Aggregate 
Throughput benchmark, which is fairly computationally 
intensive, shows better multiprocessor multipliers than 
TPC'-A. which is more I/O intensive and spends a lot more 
time in Hie kernel For a Model 870/400, the performance 
multiplier with respect to a uniprocessor is 3,6 for the SPEC 
benchmark but only 2M forTPC-A 

Another factor tending to reduce the Model S70"s multipro- 
cessor multipliers is the self-modification of the HP-l X 8.06 
kernel on uniprocessor systems, as described previously. 
The multiprocessor HP I X uniprocessor mode transpar- 
ency produces a kernel with virtually no multiprocessor 
overhead, which significantly reduces the denominator in 
the multiplier calculations. This is a depaiture from common 
practice, which is to compute multipliers with respect to 
unmodified multiprocessor code running on a uniprocessor, 

Finally, performance effects caused by applications cannot 
be ignored. In our tuning for TPC-A. a considerable amount 
of effort went into working with the database management 
system developers; to reduce the multiprocessor contention 
generated by that level of software. Database systems typi- 
cally manage their own sets of locks, which can be a great 
source of contention on multiprocessor systems. 

Application Portability 

Multiprocessor 1IP-I 'X is transparent to applications in that 
the system call interface has not changed, but there arc 
some pitfalls that application developers need to anticipate. 
In particular, applications invoking a set of cooperating 
processes are vulnerable to problems in a multiprocessor 
environment that their developers should anticipate. It is 
dangerous to assume that such applications will work cor- 
rectly on a multiprocessor system without regression test- 
ing. Although nothing needs to be modified (or even recom- 
piled) to run on the multiprocessor Model 870, some 
profound problems may be experienced 

For an application consisting of multiple processes, the 
timing characteristics will be radically different on a multi- 
processor machine. Tin- progress of execution through indi- 
vidual processes will be greatly affected by the ability of 
processes to execute concurrently on different processors. 
The consequence of this is thai timing problems may be ex- 
posed that were never seen on uniprocessors, although they 
were always possible. We have already seen this firsthand in 
moving complicated, multiple-process system tests over to 
multiprocessor systems. Careful regression testing on the 
multiprocessor system is essential to screen for liming 
I wizards. 

Applications making use of real-time priorities (rtprio) need 
to lake special care in moving to the multiprocessor system. 
Oil a uniprocessor, it is fair to assume that nothing else will 
run while the highest -priority real-time process is running. 
I lowever, on a multiprocessor system another process may 
be running in parallel with the real-time process. 



If a set of cooperating processes share a resource, for exam- 
ple a segment of shared memory, then care must be. taken to 
check whether comi>eiition for this resource negates the 
computing power available from the additional processors. 
On a uniprocessor, this is not a problem because only one 
process can lie executing at any time. However, on a multi- 
processor system, it is possible to have effectively only one 
processor because the others are waiting on the shared 
resource. 

The unit of scheduling in our initial multiprocessor imple- 
mentation is the process. Thus, there is no concurrency 
within a given program, and a single instance of a program 
will not run faster on the multiprocessor system. The benefit 
of multiprocessor operation lies in increasing system through- 
put. Although more total MIPS (millions of instructions per 
second ) are available, those Mil's are nol all available to a 
single program. 

Summary 

The IIP 9000 Model 870 multiprocessor systems are a signifi- 
cant technical milestone for IIP. These systems take HP's 
high-end HP-UX system performance to a new level, with 
Industry-leading OI.TP performance at the time of their 
release. These multiprocessor capabilities were added to 
the HP-UX system without penalizing its uniprocessor 
performance. 

The multiprocessor capabilities are Iransparenl to existing 
applications. However, the behavior of applications on a 
multiprocessor system may be different, and regression tesl- 
ing should be performed by customers moving their programs 
in the multiprocessor system. 

Transforming uniprocessor HP-UX to a multiprocessor oper- 
ating system was the largest set of modifications to the 
IIP I X system since its introduction. This project demanded 
new tools for analyzing systems and new designs to address 
the special characteristics of the Model 870 multiprocessor 
systems over more conventional multiprocessor systems. 
The development strategy of successive refinement of a se- 
quence of prototypes allowed us to focus our efforts on the 
areas of greatest return. The availability of many intermedi- 
ate systems during the course of development allowed 
greater in-house exposure to the system before release and 
resulted in a higher-quality system. 

The HP-UX multiprocessor kernel for the 9000/870 is also a 
suitable base for future multiprocessor systems with more 
and higher-performance processors. 
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Advances in Integrated Circuit 
Packaging: Demountable TAB 

State-of-the-art IC packaging, particularly with RISC architectures, 
demands performance at a high lead count. This paper presents some of 
the fundamental topics in IC packaging, formulates the principal criteria 
by which single-chip IC packages are judged, and evaluates existing 
industry-standard packages. A new packaging technology is described 
that addresses the unsatisfied packaging needs of modern digital 
systems. 

by Farid Matta 



A state-of-the-art integrated circuit can consist of millions of 
transistors in a thin small chip of semiconductor material. A 
prominent part of every chip is an array of terminal [tads, 
which include the circuits inputs and outputs and connec- 
tions to the power supplies and the system's grounds. The 
number of terminal pads in an IC is often quite large, and as 
a rule, the mure complex the chip, the more terminals it has. 
Some recent IOs have more than 500. and future chips are 
projected to contain up to a thousand terminal pads. 

In part because of their large numbers, and in part for elec- 
trical considerations, a chip's terminal pads must be very 
small. Larger pads cause the chip to be bigger than it needs 
to be based on functionality, and bigger chip sizes mean 
higher cost. At the present time, terminal pads are typically 
designed as 75-to-12">-micrometer squares on a lo0-to-250- 
micrometer pitch, and the trend is toward smaller pads and 
narrower pitches. 

IC Assembly 

Complex as it may be, a single chip rarely makes a complete 
system. Normally, a number of integrated circuits (along 
with other components) must be assembled together to 
form a useful electronic apparatus. The most straightfor- 
ward way lo do this is to mount the IC's as made (i.e., in chip 
form) onto a substrate that provides connections to I heir 
terminal pads — a concept known as hybrid or multichip 
module technology. However "natural," this approach has 
so far been limited to a few special applications for various 
technical and logistical reasons. 

Technical Issues. For the interconnection substrate lo ac- 
commodate the direct mounting of the chips, it must have 
conductor features comparable in size to the chips' terminal 
pads, While generally available, such substrates are signifi- 
cantly more expensive than standard printed circuit boards. 
The approach also requires the systems' manufacturers to 
adopt precision chip-lo-substrale bonding techniques vastly 
different from the traditional soldering processes used for 
the rest of the system, and to take responsibility for the me- 
chanical and environmental protection of the chip during 
handling, assembly, and service, ('nderstandably, few users 



are willing to make the investments and bear the additional 
cost except when there is a compelling need. 

Logistical Issues. A major difficulty in using It 's in chip form 
stems from the practical impossibility 6f performing al- 
speed lest and bum-in on bare chips. Without such testing, 
the system manufacturer runs the risk of including substan- 
dard or faulty chips in multichip assemblies. The inevitable 
result is lo scrap whole assemblies (including many good 
chips) or to expend resources on lengthy diagnosis and re- 
work. Another important logist ical hurdle is the reluctance 
of IC suppliers to prov ide their products in chip form, since 
that may reveal their product yields and cost structures, 
and would complicate accountability for product quality. 
Finally, the approach blurs the distinction between compo- 
nent and equipment reliability that can be neatly drawn in 
the alternative packaged approach 

It is no accident, therefore, that chip-on-substrate assembly 
technologies have taken hold only in vertically integrated 
companies, where logist ical barriers can be overcome more 
easily. Even then, most applications are mandated by perfor- 
mance or weight considerations that cannot be satisfied by 
the alternative approach of using packaged ICs. 

This alternative approach to building electronic systems, 
which is much more prevalent, consists in attaching pre- 
packaged components to printed circuit hoards by means of 
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solder. For an IC to be usable in such a technology, the chip 
needs to be enclosed in a package, which is expected lo: 

• Serve as a space transformer between the IC terminal pads 
and the geometries characteristic of printed circuit board 
technology' and solder-based attachment methods 

• Provide mechanical and environmental protection to the 
semiconductor chip during handling, assembly, and service 

• Allow the full testing and bum-in of the ICs by the chip 
vendor, thereby clearly fixing the responsibility and 
accountability for quality and failures. 

The low cost and maturity of printed circuit boards and the 
safety and convenience of using packaged chips have re- 
sulted in die overwhelming dominance of this assembly ap- 
proach (at least for now) over the direct chip-on-substrate 
assembly techniques. 

Categories of IC Packages 

Some IC packages may be better than others in one or more 
aspects, but most of them satisfactorily perform the three 
basic functions outlined above. There are. however, applica- 
tions in Which basic performance is not sufficient and the 
package must meet certain electrical and thermal conditions. 
Namely, in high-frequency tor high-speed) applications the 
package should present an adequate electrical environment, 
and when the chip dissipates a substantial amount of heat 
the package should provide a good conduit for that heat to a 



heal sink. We will call packages capable of satisfying these 
additional requirements "high-performance" packages, and 
the ones that cannot, "basic" packages. Fig. 1 illustrates the 
two categories of IC packages. 

Basic Packages. A typical basic package is shown schema! i- 
cally in Fig. la It consists of a metal lead frame patterned to 
match the chip's pads in the center and the printed circuit 
board s conductors on the outside The chip's terminal pads 
are attached to the lead frame by fine wires, and the whole 
structure is enclosed in a molded plastic encapsulant. Exam- 
ples of this arrangement are the dual inline package (DIP), 
the plastic quad flat pack ( PQFP), and the thin slim-outline 
package (TSOP). among others. Basic packages also exist in 
which the plastic molding is replaced with ceramic casing to 
ensure hermeticity. 

High-Performance Packages. A schematic representation of a 
typical high-performance package is shown in Fig. lb. In this 
category of packages a better electrical environment is 
achieved through the use of a multilayer substrate contain- 
ing power and ground planes as well as stripline and/or 
inieroslrip transmission lines for signal propagation. The 
chip is wire-bonded lo the substrate and covered with a 
metal lid. The most prominent example of this approach is 
the pin-grid array ( PGA). 
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Electrical Performance 

The choice of a package for an integrated c ircuit depends 
on the electrical and thermal conditions under which the 
chip is expected to operate. In other words. I he package 
must satisfy a set of electrical and thermal requirements 
formulated for the application al hand. 

The electrical operating conditions of an integrated circuit 
can be viewed as consisting of two distinct environments: 
one for signals and another for power. The requirements for 
these environments are substantially different. 

Signal Environment 

The signal's electrical environment is the arrangement of 
conductors and dielectric materials through which signals 
travel to and from the chip. Fig. 2a illustrates a typical signal 
path between two packaged tCs mounted on a common 
printed circuit board. Electrically, each segment of this path 
represents a transmission line with certain characteristic 
impedance Zq and lime delay t,| as shown in the equivalent 
circuit of Fig. 2b. Also shown in Fig. 2b are parasitic param- 
eters such as the inductances of the bond wires and package 
puis. 

The transmission-line behavior of any section of this circuit 
manifests itself only when the lime delay l,i in that section is 
comparable to the signal's switching time t s . If the delay in a 
certain segment is significantly shorter than the signal's 
switching time, that segment behaves as a lumped-parameter 
element. For example, the equivalent circuit of Fig. 2c illus- 
trates a situation in which the package's delay I,],, is much 
Shorter than the switching lime, while the board's delay t,n, 
is not. 

Al appropriately low switching speeds all of the components 
of the signal path can be viewed as lumped reactances, re- 
sult ing in the equivalent circuit of Fig. 2d. In this case the 
electrical process behaves like the simple charging of a ca- 
pacitor; hence the commonly used terms "charging" and 
"discharging" of the signal line. 

Ideal Package. For signal rise and fall times shorter than 
about 1 ns most commonly available packages must be 
treated using the transmission-line model. An "ideal" pack- 
age for such conditions should conduct the signals between 
the chip and the interconnection substrate with minimal 
propagation delay, low attenuation, minimal reflections, 
little degradation of the waveform, and weak coupling 
w ith other signals. In terms of physical attributes, these 
requirements iranslate (respectively ) to the following: 
Insulating materials with low dielectric constants 
Conductors with low sheet resistances 
Impedance control and matching with the printed circuit 
board's electrical environment 

No (or negligible) parasitic inductances or capacitances 
Low mutual inductance and coupling capacitance between 
lines. 

The equivalent circuit of such an ideal package is shown in 
Fig. :3a. Understandably, this is a technical abstraction dial 
does not exist in reality. It is shown here to illustrate how- 
real packages deviate from it. 



Basic Package. At the opposite end of the scale from I he 
ideal is the basic package whose signal environmenl is rep- 
resented by the schematic diagram of Fig. -ib. Here the leads 
are not of controlled impedance and each possesses sub- 
stantial inductance and capacitance. The parasitic induc- 
tance includes the inductances of the leads and the bond 
wires, and the parasitic capacitance to ground is uncon- 
trolled and depends on other structures. Relatively strong 
inductive and capacitive coupling ( M and ( ',. respectively mi 
the diagram ) exist between I he leads. Typical values of 
these parameters are shown in Table I for a 240-lead I'QFI'. 



Table I 

Typical Signal Environment in a 240 Lead PQFP 



Parameter Unit Value 

Lead self-inductance nil 17.50 

Mutual inductance (M) 

with nearest neighbor nH 11.12 

with third neighbor nH 8.71 

Coupling capacitance (C,.) 

with nearest neighbor pF 0.96 

with third neighbor pF 0.16 

Lead resistance ohms 0.127 



Waveform Degradation. To illustrate the significance of lead 
inductance for the signal environmenl, consider, for exam- 
ple, the condition shown in Fig. la, where a PQFP is con- 
nected lo a matched 50-olun transmission line. Ignoring (for 
simplicity) the capacitance between the leads, the circuit 
can be viewed as a low-pass filter with a lime constant 

t = L/R = (2 x 17.5 nirySO ohms = 0.7 ns. 




id 



Fig. 3. Signal environments in various pac kages, (a) Ideal, (li) Basic, 
(i i High-performance. 
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Fig. 4. Signal degradation in a basic package (a) Equivalent circuit 
(b) Effective delay. 

In approximate terms, switching can be considered com- 
plete after about 2.5 time constants as shown in Fig. 4b. 
Therefore, it can be seen lhai the presence of parasitic 
inductances in the signal environment has resulted in an 
effective time delay of almost 1.75 ns. 

High-Performance Package. Somewhere between the ideal 
and I he basic lies the category of high-performance pack- 
ages. The signal environment in these packages is schemati- 
cally illustrated in Fig. 3c. Here, the lead does represent a 
controlled-impedance transmission line, bul one thai im- 
poses a relatively long lime delay and causes finite resistive 
losses. In addition, the line includes a parasitic uncompen- 
sated inductance representing I he parts outside the multi- 
layer substrate (in the case of the PGA, for example, that 
would be the wire bonds and the pins). The use of multiple 
Conductor layers in high-performance packages can help 
reduce parasitic electrical coupling between signal lines 
compared to basic packages. However, such coupling is still 
fairly significant because the wires and pins are unshielded. 
Table II lists the electrical parameters of a 408 -pin ceramic 
PGA as a representative example of high-performance 
packages. 

Table II 

Typical Signal Environment in a 408-Pin Ceramic PGA Package 
Parameter Unit Value 

Time delay in longest lead ns 0.39 

rncompensaled lead inductance nil 2-7 

Mutual inductance 

with nearest neighbor nil 3.2-4.7 

Coupling capacitance 
with nearest neighbor 



Longest-lead resistance 



pF 
ohms 



0.5-0.7 
3.0 



Power Environment 

The package's power environment is the structure of con- 
ductors, insulators, and passive components involved in 
supplying the required voltages and currents to the chip 
within the package. An "ideal" package does not impede the 
delivery of electrical power from the power supply to the 
chip, and maintains constant potentials at the power supply 
terminals at all limes regardless of the current being drawn 
by the chip. A schematic representation of this abstraction 
is shown in Fig. 5a 



In reality, power circuits look more like Fig. 5b. For a basic 
package, the inductance represents the power lead and the 
ground lead including any bond wires. High-performance 
packages, such as PGAs. have power and ground planes and 
their parasitic inductances can be significantly lower, con- 
sisting mainly of bond-wire and pin inductances. However, 
multilayer ceramic packages typically have thin conductors 
with relatively high sheet resistance. Table III lists some typi- 
cal power-circuit parameters of basic and high-performance 
packages 

Table III 

Typical Power-Circuit Parameters in Selected Packages 

Parameter Basic Package High-Performance 

(PQFP) Package (PGA) 

Power line 17.53 nil 2-7 nil 

inductance L,, 

Ground 17.53 nH 2-7 nil 

inductance Lg 

Power circuit 0.25 ohm 0.2 ohm 

resistance 

Inductive Effects. Inductances in the power circuit cause in- 
stability of the potentials at the power and ground terminals 
of the chip. Consider, for example, the simplified case 
shown in Fig. 6a. When the circuit switches from logic low 
to logic high its output line charges through the packages 
power lead (with inductance L,,), and in the process draws a 
charging current that reaches its maximum value i ( . in a lime 
Interval t,-. Similarly, when the device switches in the oppo- 
site direction the output line discharges through the ground 
lead (wilh inductance U), sinking into the ground a dis- 
charge current that reaches its maximum value i,| in a time 
interval 

In both cases the parasitic inductances develop voltages 
that counteract (he change in current. The magnitudes of 
these voltages are determined by (he general relationship 
V = l,(di/dl ) and their polarities are as shown on I he sche- 
matic of Fig. 6a. As a result, during low-lo-high switching, 
tin- potential of the chip's power terminal drops from its 
steady-slate value V s to a temporary low V',. = V a - Lpfip/t,.). 
Similarly, during high-lo-low switching the potential of the 
chip's ground terminal rises lo a temporary bigh V,| = V K + 
b K (i,|/l,i). The first of the two phenomena is commonly 
known as power supply droop and the second as ground 
bounce. These potential swings couple directly into other 
lines connected to the same source. 

Simultaneous Switching. In practical circuits more than one 
driver will be connected to common power and ground 
leads. Fig. 6b illustrates a typical case in which four drivers 
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Fig. (i. Power efivlfOflrnent phenomena, (a) [ii'luciivc effects. 
Simultaneous switching, 

are served hy one power connection and one ground con- 
nection. If ail four drivers switch simultaneously, the cur- 
rents involved and the resulting noise will he four times as 
great as in the case jusl discussed. To illustrate the magni- 
tude of the issue consider a basic package with lead induc- 
tances of 1") nil each. If the four drivers switch simulta- 
neously from low to high in 0.5 ns drawing 20 mA each, the 
potential of the chip's power terminal would drop by 
(15xl0- ! ') x 4 x (20x10-') x 1/(0.5x10"") = 2.4 volts. During 
high-to-low switching the chip's ground terminal potential 
will rise in a similar manner. Any other line connected to the 
same source or the sanie ground will temporarily experi- 
ence a change of potential that may be sufficient to cause 
false switching. 

High-performance packages feat ure lower power and ground 
inductances, thus expanding their range of switching speed, 
driver current, or number of I/O lines per power or ground 
terminal. Another advantage is the presence of significant 
capacitances between power and ground planes. Just as 
inductance impedes instant changes in current and develops 
an EMF to counteract them, capacitance impedes instant 
changes in voltage, and supplies the necessary current to 



prevent them. The phenomenon (or technique, if imple- 
mented by design) is known as capaeitive bypassing or de- 
coupling. However, bypass capacitances help neutralize the 
effects of upstream inductances only. Therefore, in a wire- 
bonded PGA the wire inductance is not remedied by the 
power-plane capacitance. 

DC Voltage Drop. Newer chip technologies Often use lower 
supply voltages and higher currents. Some state-of-the-art 
chips draw in excess of 20 amperes. For such chips, the re- 
sistance of the conductors in die power-supply circuit ac- 
quires particular importance since the voltage drop in the 
package can be large enough to interfere witli the operation 
of the chip. Ceramic PGAs have thin conductors made of 
tungsten with fairly high sheet resistances. 

Electrical Performance Specifications 

Even the brief and simplified discussion presented here 
leads to the conclusion that packages cannot be easily speci- 
fied for a certain operational parameter such as clock fre- 
quency. The ability of a package to operate at that frequency 
will depend on many factors, such as the number of I/O lines 
per power (and ground) lead, the driver current, the capaci- 
tance of the output lines, and other factors. It is quite pos- 
sible, however, to point out the set of parameters that define 
a package electrically. Although these parameters cannot 
directly predict the package's performance in a given sys- 
tem, they can certainly be used to differentiate packages in 
terms of electrical performance. For the signal environment, 
these parameters are: 

• Impedance control 

• Minimal uncompensated inductances 

• Short delay lime, that is, low dielectric constants and/or 
short lines 

• Low conductor resistance 

• Low mutual inductances and coupling capacitances. 

For the power environment, the relevant parameters are: 

• Imw power-circuit inductance 

• Low power-circuit resistance 

• High capacitance between power and ground connections. 

Everything else being equal, the closer a package comes to 
meeting these criteria, the better its electrical performance 
will be in any system. 

Thermal Performance 

Every chip generates a certain amount of heat as pari of its 
normal operation. Depending on the technology (MOS, bipo- 
lar, etc. ), the chip's operating frequency, and a number of 
other factors, the thermal power produced can vary from a 
fraction of a watt to over 30 watts. I'nless that heal is 
constantly removed, the chip's temperature can rise beyond 
the acceptable Until for proper operation and reliability. 

For low-power ICs. the natural processes of conduction, 
convection, and radiation are often sufficient to dissipate 
the heal into the surrounding Structures and environment. 
For chips that generate more than a few watts, special provi- 
sions must be made for the adequate removal of the heat 
produced. Specifically, a constantly replenishing coolant 
(such as forced air) is employed, and a heat sink is attached 
to the IC to facilitate effective heat transfer from the chip to 
the cooling medium. 
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An ideal package would he one that allows the unimpeded 
flow of heat from the chip to the environment or to the heat 
sink. In reality, packages always present a certain thermal 
resistance to the heat flow. Pig. 7a illustrates a typical IC 
cooling arrangement in which the heat produced by the chip 
is conducted through the package to the heat sink where it 
is removed by the flowing air. T,. T c , and T a are the tempera- 
tures of the chip (junction), the package surface (case), and 
the air, respect ively. A simplified schematic of the thermal 
path is shown in Fig. 7b, where Q denotes the thermal power 
and H p and H s are the thermal resistances of the package and 
the heat sink, respectively. The variables and parameters of 
the system are connected by the following relationships: 
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These relationships show that, given a certain power Q and 
air temperature T a , the total thermal resistance B,,+H s de- 
lines the chip's temperature. Conversely, given a certain 
allowable chip temperature Tj and air temperature T a . the 
thermal resistance determines how much power can be 
safely dissipated by the chip. From either perspective, the 
thermal resistance of the package is its principal thermal 
parameter, and the lower it is the better. 

As an example, consider a 12-watt IC cooled by air that has 
been preheated (by other components) to T a = BflPG. If the 
maximum allowable junction temperature Tj is 110°C, the 
total thermal resistance should not exceed 5°CAV (from the 
equation: fl p +f) s = (Tj - TJ/Q). A practical heat sink may have 
a thermal resistance of about 3 C C/W at reasonable air veloci- 
ties, say 1 m/s. Accordingly, the package's thermal resistance 
must be below 2°C/W to satisfy the requirement. Table IV 
lists the thermal resistances of some typical packages. 

The values in Table IV are the thermal resistances of the 
packages when attached to heal sinks (but not including the 
thermal resistances of the heat sinks themselves). If a pack- 
age is operated without a heat sink, its thermal resistance 
will be significantly higher. 

In most cases the thermal conditions are much more com- 
plex than the simplified picture outlined above. Secondary 
thermal paths exist through the leads, the housing, and 
other paths. This results in a mullihranch equivalent circuit, 
but the general approach remains the same. Thermal resis- 
tances can also be strong functions of the air flow. However, 
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in most packages the junction-to-case thermal resistance is 
fairly constant. 



Table IV 

Thermal Resistances of Selected Packages 



Package Type e p | C/W| 

Basic 

Dual inline ;i • 

Plastic quad flat pack 28 

High-performance 

Ceramic pin grid array 2"> 

Ceramic PGA with thermal via holes 1 :i 

Ceramic PGA with metal heal spreader 0.45 



Thermal requirements for packages vary widely, Bipolar 
silicon and MOS GaAs devices dissipate muc h more heat 
than CMOS silicon chips. Heat generation also rises steadily 
with increasing clock frequency Ensuring the proper ther- 
mal environment for the chip is crucial, since operating at 
higher temperatures will degrade the chip's electrical perfor- 
mance and will accelerate the failure mechanisms, which 
are normally exponential functions of temperature. 

Manufacturability and Serviceability 

Although the performance pfa package is its principal 
tribute. other factors play Important roles in the design and 
selection process. Prominent among those are cost, reliability, 
manufacturability, and serviceability, Cost and reliability are 
straightforward, easily quantifiable parameters. Manufactur- 
ability and serviceability require some elaboration, and to- 
wards that end a brief overview of printed circuit assembly 
methods may be helpful. 

When (he packaged K 's. along with other components such 
as connectors, passive parts, and so on, are mounted on a 
printed circuit board, the result is a printed circuit assembly, 
which is the main building block of most electronic equip- 
ment. The design and fabrication of printed circuit assemblies 
is carried out in one of three ways: 

Through-Hole Technology (TUT), This traditional approach 
involves inserting the components' leads into holes in the 
printed circuit board before performing the soldering opera- 
tion. The mounting holes, passing all the way through the 
board, waste much of the area av ailable for Interconnections 
in the board's inner layers, thus complicating its mutability 
and limiting its density. 



T. 




Fig* 7. IC cooling, (a} typical 
arrangement do Bqutvaleni 

circuit 
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Surface Mount Technology (SMT). This more modem ap- 
proach is based on soldering the components to pads on the 
surface of the printed Circuit board, thus freeing more of the 
area of I he inner layers for routing. It also allows double- 
sided assembly for even grealer packing density. The current 
trend is toward a greater proliferation of SMT. 
Mixed Assembly. Most basic packages are available in SMT- 
conipatible versions, but high-performance packages and 
some other components are still predominantly of the 
through-hole variety. As a result, some high-performance 
printed circuit assemblies, such as in computer applica- 
tions, must use a mixed TIIT-SMT assembly process, which 
puts conflicting demands on the const met ion, metallurgy, 
and thickness of the printed circuit board and on the 
parameters of the soldering process. 

Not all printed circuit assembly designs are equally suited 
for efficient, easy, and economical manufacturing. If a 
manufacturability index is formulated for printed circuit 
assemblies, it should include the following factors: 
Number of Processes. Lower score for products requiring 
more than one attachment method — for example, solder 
reflow and wave soldering. 

Process Window. Higher score for wider process window. 
( 'omponent Preteslability. Higher score for the ability to test 
all components fully before assembly. 
In-Process Testing. Higher score for the ability to test a 
complex assembly at intermediate points during the 
fabrication process. 

Base of Rework. Higher score for easier diagnosis and re 
work, particularly of the more expensive components, and 
for multiple chances to rework. 

Product -Specific Fixturing. Lower score for the need to 
change production fixluring for different products. 

When a hardware failure occurs in an installed system, it is 
typically diagnosed to the board level, and the culprit board is 
replaced and returned to the factory for diagnosis and repair. 
In much the same way as for manufacturability, a service- 
ability index can be developed to judge various packaging 
options. It should be based on the following factors: 
Component Replaceahility. Higher score for easily removable 
parts. In addition to reducing the time and cost of physical 
repair, readily demountable parts facilitate diagnosis and 
access to other components. 

Component Testability after Removal. Higher score if the 
components remain intact and testable after removal. This 
eliminates unnecessary scrap, helps provide meaningful 
feedback to component suppliers, and helps build a 
database for effective troubleshooting. 
( )n-Site Repairability. Limiting on-site repair to the board 
level necessitates stocking a variety of expensive printed 
circuit assemblies in service centers around the world. The 
ability to diagnose and easily replace a bad component at 
the customer's site can produce sizable savings. 

Compatibility of 1C packages with advanced assembly meth- 
ods (namely with SMT) and with manufacturability and ser- 
viceability criteria are becoming increasingly important. 
While basic packages generally meet the manufacturability 
requirements, and to a lesser degree the serviceability crite- 
ria, high-performance packages do nut score high on either 
account. 



PGAs, for example, require mixed assembly, manual inser- 
tion, and application-specific fixluring. A printed circuit as- 
sembly that contains PGA packages cannot be reworked 
more than once or twice, and the rework process is tedious 
and messy and requires highly skilled technicians. Rework 
tune estimates vary from 45 minutes to two hours per pack- 
age, and the packages are ruined and (intestable after re- 
moval. In addition, certain future reliability hazards are 
often inflicted on the rest of the assembly as a result of the 
rework and repair process. 

Package Fundamentals .Summary 

Basic' packages are simple and inexpensive. They meet most 
of the manufacturability and serviceability requirements, but 
electrically and thermally they are suitable only for nondc- 
manding applications. Conventional high-performance pack- 
ages, such as PGAs, provide significantly better electrical and 
t henna! environments. However, I hey are fairly expensive and 
fail to meet most manufacturability and serviceability re- 
quirements. Their electrical performance is likely to become 
inadequate as signal rise and fall times drop below 1 ns. 

Demountable TAB 

Having defined the principal criteria used to evaluate single- 
chip IC packages for digital applications, and having re- 
viewed the stale of the art, we now proceed to describe a 
new technology that has been developed in response to Hie 
shortcomings of existing solutions. The technology is based 
on tape automated bonding (TAB). 

Tape Automated Bonding (TAB) 

TAB was originally conceived as a way to avoid wire bond- 
ing by attaching the lead frame directly to the chip. Since 
conventional, self-supporting lead frames could not be 
made with features fine enough to mate directly with the 
chip's pads, the method uses thinner lead frames laminated 
on a supporting dielectric film. The latter is typically fabri- 
cated in tape form with sprocket holes for automated 
manipulation; hence the term tape automated bonding. 

Fig. 8a presents an example of a chip mounted on a TAB 
frame, used to replace the wire bonds in a standard pack- 
age. The TAB frame's inner leads are bonded to the chip, 
while the outer leads are attached to the package's conven- 
tional lead frame. TAB can also be used for direct attach- 
ment to the printed circuit board as shown in Fig. 8b, in 
which case the method is know n as TAB on board (TOB). 

TAB Advantages 

TAB (specifically TOB) offers the advantages of lower cost, 
lighter weight, and lower-profile assembly. Therefore, it is 
used widely in consumer products and low-cost technical 
applications. It has also turned out to be an attractive op- 
tion for computer applications, for reasons of cost and 
performance. 

The performance advantage consists in TOB's suitability for 
denser chip I/O geometries and finer printed circuit board 
features, and in its smaller footprint and lower electrical 
parasitics. When TAB frames are made with two conductor 
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Fig. 8. Tape automated bonding (TAB) strurturos. (a) TAB in pack- 
age, (b) TAB OA board (TOB). 

layers the signal leads ran be designed as controlled- 
impedanee inicrostrip lines, as will be shown later. The thick 
copper conductors (O.o to 1 oz/ft 2 ) and the low dielectric 
constant Of the polyimide insulator (3.4) account for low 
losses and short electrical length, respectively. Additional 
advantages are round in TAB's shorter design and fabrica- 
lion cycles compared to other high-performance packages 
(e.g., PGAs). and in its preassembly testability, an important 
feature not found in other chip-on-board assembly 
approaches. 

TAB Drawbacks 

( )n l he other hand, TAB has some shortcomings, chief 
among which are enlry barriers, such as high startup cost, 
and lh«' difficulty of rework and repair. 

The startup cost barrier affects both the chip supplier and 
the equipment manufacturer. For the chip maker, getting 
inlo TAB entails substantial startup investments in special- 
ized wafer-burapiqg and inner-lead bonding facilities. The 
tadtetry-standard inner-lead bonding (I LB) process requires 
"bumping" the Chip's I/O pads, that is. growing miniature 
gold bumps (0 which the TAB inner leads will be bonded. 
This is a fairly expensive proc ess that requires special ex- 
pertise and a large initial investment. Since bumping is done 
at the wafer level, I he per-chip cost increases steeply at low 
wafer-sort yield (typical for advanced chips). 

For the system manufacturer, the outer-lead bonding (OLB) 
processes also require expensive equipment with Inherently 
application-specific tooling and relatively low throughput 
For example, an outer-lead bonder with a throughput less 
than 10,000 TAB sites a month costs more than U.S.SfiOO.OOO. 
requires a lead-form and excise module costing about 
F.S.$ 100.01 10, and requires a Ihermode costing over 
F.S.$10,000 for every TAB geometry in use. Most important, 
however, TAB represents a radical change in the board as- 
sembly culture, a change that requires significant physical, 
logistical, and behavioral modifications on the shop floor. 



TOB packages are even more difficult to rework or repair 
than PGAs, especially at higher lead counts when the outer- 
lead pitch is very small. The task becomes even harder when 
the chip is attached to a heat spreader. Some laborious, 
barely acceptable techniques do exist, but they invariably 
entail the destruction of the chip and some damage to the 
board. Typically, such methods can be used only once on 
any specific TAB site. None of these methods was suffi- 
ciently practical to find acceptance in the industry. At the 
present time it is fair to say that TOB packages are basically 
not reworkable. 

Therefore, despite TAB's advantages of higher electrical 
performance and lower cost compared with other packaging 
methods, its proliferation in the industry has been extremely 
slow and mostly limited to low-cost coasumer products. 
Obviously, to potential users in the computer and instrument 
industries the issues of high startup cost and the difficulty of 
rework and repair have been sufficient to outweigh TAB's 
benefits. 

Demountable TAB 

Our solution to t his problem is a version of TAB that, while 
maintaining the advantages of better performance and lower 
cost, does not require expensive facilities and is easy to de- 
mount for rework and repair. This solution was developed 
at HP's II' Business Division R&D center. It is called 
demountable TAB, or DTAB. 

The demountable TAB idea is fairly simple. It is based on 
using a TAB structure that differs from the standard imple- 
mentation in two ways. First, the expensive, bumped, inner- 
lead bonding operation is replaced with a simple bumpless 
process. 1 - Second, the soldered outer-lead connections are 
replaced with separable pressure contacts. 

Bumpless ILB lowers the TAB entry barrier for the chip 
maker by obviating the need for capital-intensive wafer- 
bumping facilities. Similarly, the solderless outer-lead cou- 
ncil ions allow the user to adopt TAB without the associated 
investments and profound changes in the assembly culture. 
Demountabilily also completely removes the other major 
drawback of conventional TAB. that is, the difficulty of 
repair and rework. 

DTAB Structure 

Fig. 9 illustrates the basic structure of the DTAB package. 
As received by the user, it consists of two parts: the package 
proper, and a spring/stiffener. The spring/stiffener is 
mounted on the opposite side of the printed circuit board 
to enhance Its Stiffness and to provide the spring action 
necessary for the pressure contact. 

The package contains four protruding alignment bosses, and 
the printed circuit board has a set of matching holes. Mount- 
ing the package on the board consists merely of inserting 
the bosses inlo the holes and attaching the spring/sliffener 
on the backside of the board. The structure is sell-aligned 
and one of the pin/hole pairs is offset so the package can be 
inserted only in the correct orientation. 

Hie main element of the package is the TAB frame, which 
carries the IC. It is oriented so that its circuit side faces the 
printed circuit board while the back or the IC is attached to 
a heal spreader which doubles as a mechanical clamp. The 
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Fig. 9. SlriKluri' >if tin- i!ciinniiit;ih|i' TAB (UTAH) par-kage 

TAB frame and the printed circuit board contain gold-plated 
pads which come into contact with each other when the 
package is mounted onto the printed circuit hoard. The 
spring/stiffener, together with an elastomeric planarizer 
backing the TAB flame, form a composite spring system 
designed to ensure that the outer-lead contacts are made 
and maintained under various operating conditions. 

An example of a DTAB package with 432 leads is shown in 
Fig. 10. The outer-lead contacts on the TAB tape are ar- 
ranged in an area array configuration, an arrangement that 
packs a large number of contacts into a relatively small area 
wit In ml requiring a fine-pilch printed circuit board technol- 
ogy or overly light tolerances on the holes. For example, 
this 432-lead package has a footprint 5 cm (2 in) on a side, 
and the required printed circuit board can be made using a 
technology as coarse as 200-mierometer f0.008-inch) lines 
and Spaces with standard hole tolerances. In this design, a 
misregistration of 25(1 micrometers (0.010 inch) can be toler- 
ated without danger of losing continuity or shorting to 
neighboring contact pads. 
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Fig. 10. M2-lea.l DTAB package 



Advantages of DTAB 

DTAB not only avoids TAB's drawbacks while maintaining 
its advantages, bill also adds a number of valuable features 
of its own. In product development. DTAB removes many of 
the Constraints imposed on the printed circuit assembly de- 
sign by mixed-assembly requirements. Easy demountability 
facilitates debugging in the breadboard phase. In manufac- 
turing, it provides preassembly testability, unlimited rework- 
ability, and ease of troubleshooting. DTAB does not upset 
established print etl circuit assembly practices and fits easily 
into existing production lines. Another potential advantage 
is the possibility of having the printed circuit assembly with- 
out VLSI chips fabricated where manufacturing costs are 
lowest, then adding the DTAB-paekaged VLSI chips just 
before shipment of the end product. 

The importance of testability in manufacturing cannot be 
overstated and deserves more elaboration. Testability is one 
of the main advantages of TAB in general. However, to ac- 
commodate test pads for all the leads in the conventional 
technology, the TAB frame must be made much larger than 
it otherwise needs to be. An expensive fixture is used to 
access those pads, and the resulting electrical environment 
is so inferior to the actual system that the test coverage is 
often quite poor. It is also extremely difficult to cool a chip 
on TAB adequately during test and bum-in if lhal is required. 
In contrast, DTAB needs no test pads on the tape. The test 
fixture can be a simple DTAB site on a printed circuit board 
identical to the one on which the package will eventually be 
mounted, fooling is handled in exactly the same way as in 
the assembled product. 

In product support, the readily demountable DTAB package 
makes it easy to diagnose and repair faulty printed circuil 
assemblies. It makes troubleshooting and servicing the 
equipment possible at the chip level at the customer's site, 
which may eliminate the need to stock expensive subassem- 
blies at many service centers around the world. Another 
major advantage is the possibility of field upgrades on the 
chip level. 

The Cost of DTAB 

DTAB's benefits do not come without cost. The concept im- 
poses two special requirements on the printed circuil board: 
a noble finish on the traces, and four alignment holes on each 
site. The impact of these requirements varies depending on 
the specific application. 

Trace Metallurgy. For the pressure contact to be reliable, the 
printed circuit board's copper traces must be coated with 
gold over a nickel barrier. The minimum gold thickness that 
has been characterized for reliable operation is 0.127 micro- 
meters (5 microinches). The recommended thickness of the 
nickel barrier is 2.54 micrometers ( 100 microinches) or 
greater. 

Alignment Holes. The alignment holes add to the cos I of the 
primed circuit board in two ways. First, they use up some 
board area which might Otherwise have been used for rout- 
ing. This is a minor issue, and its effect on cost is negligible. 
Secondly, the required tolerances on hole size and place- 
ment are +50 and +125 micrometers (0.002 and 0.005 inch), 
respectively. While printed circuit board shops will normally 
provide a placement tolerance of about 100 micrometers, 
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meeting ihe size tolerance may require that the holes remain 
unplated. Therefore, they should either 1m? drilled separately 
at the end (post -drilling) or "tented" to prevent side-wall 
plating. Either option implies some additional cost. 

Mechanical Considerations 

In general, three principal elements in the concept and the 
design of DTAB can be credited for its successful operation. 
These are a flexible canted element, a composite, controtled- 
relaxation spring system, and sealed contac ts. 

Flexible Contact Element, In theory, when two rigid bodies are 
brought into contact, only three points on each are actually 
touching. 1 However, when one of the two elements is flex- 
ible, as is Ihe case in DTAB. the contact area is larger, the 
resistance is lower, and the electrical connection is more 
reliable. 

Controlled-Relaxation Spring. Previous designs for pressure 
contact systems used an elastomeric spring to provide the 
contact force. The effects of time and temperature cause 
elastomeric materials to relax and lose up to 60% of the orig- 
inal stress, and accordingly, retain less than half of the initial 
force. They also have difficulty maintaining the contact pres- 
sure during thermal cycling, because of hysteresis. DTAB 
uses a composite spring system in which the loss of stress is 
minimal. The composite spring system is described in more 
detail later, 

Contact Shielding. A major failure mode in pressure contacts 
is the corrosion of the contact surfaces in chemically aggres- 
sive environments. In DTAB. the contacts are virtually 
sealed and the circulal ion of corrosive agents around the 
contacts is all but eliminated. 

Fig. 1 1 shows a cross section of the package. The heat 
spreader/clamp is made of a copper-niolyhdcn urn-copper 
laminate and the alignment frame is of molded plastic. The 
cont rolled-relaxation composite spring system consists of 
the elastomeric planari/.er backing Ihe TAB frame in series 
with the nonrelaxing metal spring/stiffener on ihe opposite 
side of Ihe prinled circuit board. 

Fig, 12 shows Ihe basic dimensions of Ihe DTAB package. 
The Bust tWO members of the package family are DTAB-284 
(replacing Ihe 272-pin PGA), and DTAB 432 (replacing the 
108-pin PGA). DTAB-284 and DTAB-432 are 3.75 cm (1.5 in) 
square and 5 cm (2 in) square, respectively. In comparison. 
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Fig. 12. UTAH package dimensions, 

the 272-pin PGA and Ihe 108-pin PGA are 5.33 cm (2.1 in) 
Square and 5.84 cm (2.3 in) square, respectively. 

Composite Spring 

Fig. 13 illustrates the effect of the composite spring. Fig. 13a 
shows qualitatively how an elastomeric spring relaxes (i.e., 
loses stress at a given strain ) with time. Depending on the 
temperature, the relaxation typically lapers off at about 40% 
to (50% of the initial stress. In ihe composite spring, the metal 
spring compensates for Ihe relaxation of the elastomer so 



Time 



(a) 



'/////// 



Time 




(b) 



Fig. 13. Spring relaxation, (a) Klasl inner only. (Ii) 
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Fig. 1 1. 1'mss section "I' ii »' i >t\h package. 
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Fig. 14. ( Iperatloii ofa composite spring. 

Ihal the overall loss or force is considerably reduced, as 
shown in Fin. '3b. 

A simplified mathematical description of the phenomenon 
can be obtained by analyzing the series connection of t wo 
linear springs Willi spring constants kj and lo> (Fig. Kiel. 
Assume that one of the springs, say k|. is a relaxing type 
with force retention ri, thai is. i"| is the fraction of the origi- 
nal force remaining in that spring after relaxation under 
constant strain. Assume also that Ihe other spring is nonre- 
laxing with force retention r-i = 1. It can be shown that Ihe 
overall force retenlion R in the composite system is: 



Therefore, by adjusting ihe ratio of stiffnesses ktfk\, one can 
control the loss of stress in the composite system. Force 
retenlion R can be increased by reducing the ratio Wki. 

The physics of the composite spring is illustrated by Fig. 14. 
The diagram represents a graphical method of rinding equi- 
librium stresses and strains in the composite system. The 
stress/strain curves of the two springs are plotted with one 
of them mirrored around the stress axis. When the curves 
are spaced apart by an amount equal to Ihe total system 
strain, the intersection point corresponds to the equilibrium 
stress. Conversely, if the stress is known and Ihe curves are 
placed such thai they intersect al that stress, the distance 
between them on the abscissa shows the total strain. The 
segments of Ihe abscissa enclosed between the intersection 
point and the origins correspond to the component strains. 

When Ihe elastomeric spring relaxes, its stiffness is reduced, 
and its stress/strain curve shifts to the position represented 
by the dashed line in Fig. 14 The equilibrium Stress drops 
from point (a) to point (b). If the system consisted of an 
elastomeric-only spring, the stress would have dropped to 
the lower point (c) instead. In addition to illustrating Ihe 
physics of the composite spring, this graphical method can 
be used for the accurate analysis of real nonlinear systems. 
( Further discussion of the composite spring can be found in 
reference 4.) 

Assembly of the DTAB package on the printed circuit board 
consists of lorquing the the fasteners with a certain moment. 



which corresponds lo a specific mechanical slress in the 
system. 

Electrical Considerations 

i"he main electrical structure in the DTAB package is Ihe 
TAB frame. Depending on the required performance, a 
single-metal or a double-metal tape may he used. The single- 
metal version, whose cross section is shown in Fig. 15a, is 
considerably less expensive but offers limited high-frequency 
capabilities (similar to basic packages). In the double-metal 
Structure (Fig. 15b) each lead, together with the common 
ground plane, forms a microstrip Iransmission line with a 
characterist ic impedance of about 50 ohms. Such a Structure 
represents a much better electrical environnienl for high- 
frequency signal propagation than the single-melal version. 

DC Parameters 

The main dc parameters of the DTAB package are the resis- 
tances and the current -carrying capabilities of the leads and 
thi' contacts. 

Lead Resistance. The width of Ihe signal leail (50 microme- 
ters or 0.002 inch) is chosen to form a 50-ohin microstrip 
line with Ihe ground plane and Ihe polyimide insulator. The 
total lead resistance is proportional to ihe lead length, 
which is a function of Ihe package size and of the position of 
Ihe lead on Ihe TAB frame. Willi the typical 1-oz/ft- copper 
on the signal side the lead resistance values are 0.06 lo 0.15 
ohm for DTAB-284 and 0.07 to 0.17 ohm for DTAB-432. 

Contact Resistance. Difficuli to calculate, the contact resis- 
tance has been empirically defined. Based on tens of thou- 
sands of measurements. Ihe observed values are typically 
about 0.8 milliohin and do not exceed 2.0 milliohms. 

Current-Carrying Capability. This parameter, although of great 
interest, is hard to specify, mainly because of the lack of 
definition of what it means for Ihe case at hand. Al the time 
of this writing, both the 0.0()2-inch lead and the individual 
contact point have been proven able to sustain indefinitely a 
dc current of at least 0.3A without change in resistance or 
appearance. This, however, is only a data point rather than a 
limit or a specification. 

AC Parameters 

As discussed earlier, for a package not to degrade Ihe per- 
formance of the chip it houses, the package should prov ide 
a clean environment for signal propagation and unimpeded 
access by Ihe chip to the power supply. A clean electrical 
environment means a Iransmission line of uniform known 
characteristic impedance, with minimal parasities and 
losses, free from coupling with other signal lines. I'nimpeded 
access to the power supply means low-impedance power 
leads with minimal series inductances to cause Ldi/dt 
potential bounce. 

Copper Leads 




Ground Plane 

Ibl 



Fig. 15. TAB cross sections, (a) Single-metal; (10 I iniible-nit t.il 
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Signal Environment. The signal propagation environment in 
DTAB is shown in Fig. 16a- Two signal leads are drawn to 
illustrate coupling effects. A microstrip line is formed by 
each lead, the underlying ground plane, and the dielectric 
sandwiched between them. The equivalent circuit of the 
signal propagation emironment is presented in Fig. 16b. The 
small parasitic inductance of 0.18 nil represents the uncom- 
pensated portion of the inner lead protruding beyond the 
edge of the ground plane. 

The line delay and the mutual parasitics between lines are 
proportional to the lengths of the traces. Therefore, each of 
these parameters varies within a range for a given package. 
Table V lists the values obtained by validated modeling. 

Table V 

Signal Environment Parameters in DTAB 
Parameter DTAB-284 DTAB-432 

Line delay, (ps) 50-60 80-100 

Uncompensated inductance (nil) 0.18 0.18 

Mutual inductance (nil) 

with 1st neighbor 0.61-0.88 1.1-1.6 

with 3rd neighbor 0.13 0.14 

Coupling capacitance 

with 1st neighbor 0.06-0.08 0.13-0.18 

with 3rd neighbor 0.002 0.004 



Power Environment. A power supply line on the tape should 
have the lowest possible impedance. Lower inductance will 
reduce Ldi/dt effects, and liigher capacitance will help isolate 
tile circuit from voltage fluctuations in the rest of I he system. 



Therefore, a power supply line should be as wide as possible. 
Additional capacitive bypassing should be available as close 
to the device as possible. 

Depending on the tape layout, a power supply line in a 
DTAB package can be as narrow as a signal line, or signifi- 
cantly wider, as shown in Fig. 17a. Available space and the 
criticality of the power line in question will dictate to the 
package designer the actual width. For typical situations in 
our experience, the power environment parameters are as 
shown in Table VL 

Table VI 

Power Environment Parameters in DTAB 
Parameter DTAB-284 DTAB-432 

Total line inductance (nH) 0.5 0.85 

Total line capacitance (pF) 6 8 

Sheet resistance (ohm/square) 0.5 0.5 

Bypass capacitors may be placed in the locations shown in 
Fig. 18. Assuming a 0.070-inch-thick printed circuit board, 
the physical distances between the bypass capacitors and 
the chip pads are shown in Table VII. Comparing the physical 
distances separating the bypass capacitors and the chip pads 
in (he DTAB packages with their counterparts in ceramic 
PGAs, it is clear that the differences are fairly insignificant. 
However, if a critical application does demand that bypass 
capacitors be closer to the chip, they can be mounted di- 
rectly on the TAB frame. This approach has not been for- 
mally qualified, but its feasibility has been proven in the 
laboratory. 
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Fig. 16. Signal environment to the 432-lead utab package, (a) 
Structure. n>) Equivalent cUictdl 
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Fig. 17. Power environment in the 432-lead UTAH package, (a) 
Structure (l>) Equivalent circuit. 
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Fig. 18. Available locations 
packages. 
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Table VII 
Distance to Bypass Capacitors 

Parameter DTAB-284 DTAB-432 408 PGA 

Shortest trace (in) 0.454 0.499 0.435 

Longest trace (in) 0.725 0.974 0.770 

The DTAB concept offers additional options for enhancing 
the power environment — for example, segmenting the 
ground plane to reduce coupling between clean and dirty 
power sources and using a three-metal tape. 

Table VIII lists some important electrical package parame- 
ters for DTAB-432 and its closest ceramic pin-grid array 
counterpart (408-pin CPGA). 

Table VIII 

Comparison between DTAB-432 and 408 PGA 



Parameter 


DTAB-432 


408 PGA 


Uncompensated line inductance 


0.18 


2-7 


(nH) 






Line delay (ps) 


80-100 


300-400 


Mutual inductance (nil) 


1.1-1.6 


0.5-0.7 


Coupling capacitance (pF) 


0.13-0.18 


0.5 


Total line inductance (nH) 


2.50 


4.6-6.0 


Distance to bypass capacitor (in) 


0.50-0.97 


0.44-0.77 


Sheet resistance (mohm/square) 


0.5 


12 



System Performance 

It was argued earlier that the parametric performance of a 
package is not a sufficient ( although necessary) condition 
for adequate operation in a system, since the operation de- 
pends greatly on the engineering of the system. The system 
performance of DTAB has been evaluated in two challeng- 
ing situations. The evaluations were conducted initially by 
simulation, and then the results were verified by direct 
measurements. 

DTAB-432 in a 65-MHz System. A custom processor chip used 
in various HP computer products is normally housed in a 
408-pin ceramic PGA A simulation was conducted to predict 
its behavior in a DTAB-432 package at a clock rate of 65 MHz. 
The summary of the results is shown in Table IX. which 
compares the most pessimistic DTAB conditions to the most 
optimistic PGA operation. This simulated performance was 
subsequently validated by testing. 



Table IX 
DTAB-432 in a 65-MHz System 

Parameter Unit 408 PGA DTAB-432 

Cache address rise time ns 4.2 3.9 

Ground bounce energy relative 1 0.47 

Logic V,],i bounce relative 1 I 

Maximum crosstalk relative 1 1.23 

DTAB-432 in a 125-MHz System. A proprietary test chip was 
designed to operate at 125 MHz. A simulat ion was run to 
compare the operation of the chip housed in a DTAB-432 
package and in a 408 PGA. Table X summarizes the results 
of those simulations. They indicate the overall superiority of 
the DTAB package in a system context. These results were 
also validated by measurements, as shown in the table. More 
details on this exercise can be found in reference 5. 

Table X 

DTAB-432 Performance at 125 MHz 



Parameter 


Unit 


408 


DTAB-432 






PGA 


Simulated 


Measured 


Reflected noise 


mV 


490 


145 


160 


Crosstalk 


mV 


325 


125 


144 


Dc IR drop 


mV 


102 


23 




Signal delay time 


ps 


200 


150 




Common-mode noise 


mV 


N/A 


425 


275 


Differential-mode noise 


mV 


N/A 


125 


40 



Thermal Considerations 

The main thermal path in the DTAB package is through the 
heat spreader to the heat sink. A secondary thermal path 
exists through the TAB frame's leads and ground plane to 
the prinled circuit board. The components of the main ther- 
mal path are the chip, the die-attach material, the heat 
spreader, and the heat-sink-attach material. 

Although the material of the heat spreader (Cu-Mo-Cu) and 
its geometry were selected mainly to satisfy certain strin- 
gent mechanical requirements, the thermal environment of 
the package is at least equal to the best commonly used heat 
spreader materials. Table XI presents a comparative chart. 



Material 

Cu-Mo-Cu 
Cu-Invar-Cu 
Cu-Kovar-Cu 
Cu-W 
Note: Si 



Table XI 
Heat Spreader Materials 

Temperature Coeffi- Thermal Conductiv- 
cient of Expansion ity (W/cm-^C) 
(xHHV C) 



5.07 

5.3- 6.7 

7.4- 8.7 
6.5 
2.6 



2.08 
1.88 
2.30 
2.00 
1.50 
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The die-attach material is an industry-standard silver-filled 
epoxy-based adhesiv e with a thermal conductivity of 0.02 
\V/cm-~C. The heat-sink-attach material is optional. In cer- 
tain applications the heat sink is glued to the heat spreader 
with silver-filled epoxy; in others, demountability of the heat 
sink is required, and the epoxy is replaced with thermal 
grease. 

The thermal performance or the DTAB pac kage has been 
characterized at power dissipations up to 40 watts. Table XTJ 
lists the components of the thermal resistance of the DTAB 
package and their values measured at an air flow of 1.5 nv/s. 

Table XII 
Thermal Resistances 



Thermal Component 

Die attach epoxy 
Heat spreader 
Heat sink attach epoxy 
Subtotal junction-to-case 



Thermal Resistance ( C/W) 

0.12 
0.08 
0.08 
0.33 



Measurements conducted at various air flow rates are 
shown in Fig. 19 for a 432-lead DTAB package with a stan- 
dard extruded aluminum heat sink. The change in the total 
thermal resistance is a result of the heat sink characteris- 
tics, while the thermal resistance of the package remains 
constant Ihroughout the range of measurements. The DTAB 
package is compatible with virtually any heat sink or heat- 
sink-mounting configuration selected by the user. 

Sometimes the power dissipation of the chip is sufficiently 
low that a heal sink is not required. In that case, the . junction- 
to-air thermal resistance of the DTAB-132 package is 8.4 °CYW. 

It is useful to compare these values with the best commer- 
cially available packages. For example, the expensive 
"slugged" 108-pin ( PGA has a junction-to-case thermal 
resistance of 0.45 °C/W. The less-expensive slugless version 
has a junction-lo-case thermal resistance of 1.3 °CAV when 
attached to a heat sink. 

Reliability 

To develop a reliable product in the shortest possible time, 
reliability testing has to start, very early in the development 
phase and continue to be used as a development tool 
throughout the process. This is termed "developmental reli- 
ability testing" to distinguish it from the formal reliability 
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qualification that takes place before the manufacturing 
release of a new technology. 

For DTAB. possible failure modes were identified based on 
observations, experience, and theoretical reasoning Certain 
stresses were defined to which the failure mechanisms were 
deemed particularly sensitive, and these stresses constituted 
the battery' of developmental reliability tests. Table XTJJ 
presents a list of these tests and the conditions under which 
they were conducted. 

Table XIII 

DTAB Developmental Reliability Tests 
Test Code Conditions 

Temperature/humidity 85/85 85°C. 85% RH 

Thermal aging TA 105 3 Cinair 

Thcrmal cycling TC -55 to 85°C in air 

Liquid thermal shock ITS -55 to 125°C 

Corrosive atmosphere CA H2SO4/SO2/CI2/NO2 

@25°C, 70% RH, 96hr 

Mechanical vibration MV Random, 15g, 

0.06-inch amplitude 

Mechanical shock MS 2.5 ms, 6 axes 

Table XIV shows a mat rix of the potential failure mecha- 
nisms and the stresses designed to reveal them. The matrix 
demonstrates that all suspected failure modes are being ad- 
dressed by at least one test, and, in some cases, by up to six 
tests. The test codes in Table XTV are defined in Table XIII. 

When the development effort was deemed complete, a for- 
mal product qualification was performed according to the 
protocol summarized in Table XV. 

In addition to these tests, a separate formal qualification of 
tape via integrity was conducted using specially designed 
coupons containing a total of 46,400 vias. The coupons were 
subjected to MAST (highly accelerated stress testing), ITS 
(liquid thermal stress), and high-temperature storage. 

Alpha-Site Testing 

After much of the development work was completed, two 
HP alpha sites were selected to demonstrate the operation 
of the package in real computer products. The products 
were selected to cover both through-hole and surface mount 
printed circuit assembly technologies, single and multiple 
VIvSI assemblies, minicomputer and workstation products. 

Bus Converter Board. This printed circuit assembly, used in a 
variety of computer products, is built on a 12-layer t hrough- 
hole printed circuit board with nickel/gold surface finish. 
The bus converter chip is the only VLSI chip on the board. It 
is a 9-mm-by-9-mm NMOS device with 272 I/O pads, and is 
normally housed in a 272-pin PGA package. The bus con- 
verter chip operates at a 27.5-MHz clock frequency and an 
8-MHz out put rate, and dissipates 8 to 10 watts. 

The strategy of the test was to package the bus converter 
Chip in DTAB and redesign the bus converter board to ac cept 
the new package without disturbing the other components. 



Fig. 19. thermal resistances in (he 432-lead DTAB package. 
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Table XIV 

OTAB Stress/Failure Developmental Reliability Matrix 

Stress 



Failure 

Elastomer 
Relaxation 
Emhrittlement 

Printed Circ uit 
Board 
Flow 

Mechanical 
degradation 

Contacts 
1 ) illusion 
Oxidation 
Corrosion 
Fretting 
Contamination 
Electrochemical 
phenomena 

TAB Tape 

Trace peeling 
Via failure 
Trace failure 

Chip 

ILB separai i< in 
Encapsulation 

failure 
Die attach 
separation 



85/ TA TC LTS CA MV MS 
85 



X 
X 



X 
X 

X 
X 



X 
X 



X 



X 
X 



X X 



X 
X 



X 



X X 



X 



X 
X 



XXX 

X X X X X 
X X X X 



Five DTAIJ printed circuit assemblies were built and sub- 
jected to standard production testing and environmental 
qualificat ion. The redesign of the board turned out to be a 
fairly simple task, and all tests were successfully completed. 

Processor Board. This workstation processor board contains 
six VLSI chips, all of which are '.I nun by 9 mm and have 272 
I/O pads. The chips are normally housed in 272-pin ceramic 
PGAs, and the board is all surfac e mount technology except 
for the PGAs. The system's clock rate is 30 MHz. and the 
maximum power dissipation per chip is 12 watts. 

Ten DTAB printed circuit assemblies were built and exer- 
cised in operational workstations. They passed the full pro- 
duction lest, and then were subjected to HP class C reliabil- 
ity testing, which they successfully passed. At the time of 
this writing, the assemblies have been functioning without 
failure in operational workstations for over two years. 

Fig. 20 shows a photograph of the DTAB package used for 
both of the alpha-site exercises just described. As can be 
seen from the picture, the outer-lead contacts are arranged 
as a linear peripheral array rather than an area array. Periph- 
eral DTAB is the original and more logical technical solu- 
tion. Area DTAB was conceived as a response to customer 
concerns about the availability and cost of the fine-pilch 
printed circuit boards required for peripheral TAB. The pack- 
age of Fig. 20 has 272 leads on a 400-micrometer (0.016-inch ) 
outer-lead pitch. Peripheral DTAB designs with outer-lead 



Table XV 

DTAB Reliability Qualification Protocol 

Sample Test Conditions 
Size 



Test 

1. Package: 

HAST* 34 

Thermal cycling -lo 

Liquid thermal shock 78 

Thermal aging 129 

Mechanic al vibration 32 

Mechanical shock 32 

Ozone exposure 30 



125°C, 85% RII, 1-1 psi, 
5V bias, 90 hr 

-55 to 150°C, 500 cycles 

-55 lo 150°C, 200 cycles 

110°Cinair, 1500 hr 

Random, log, 
0.00-inch amplitude 

CJOOg, 2.5 ms, 6 axes 



2. Package-to-Board Connections: 



Contact resistance" 

Mating/denial ing" 

liquid thermal shock" 

Thermal aging" 

Industrial 
environment* 

Moisture resistance 

Insulation resistance 
Dielectric withstand 



20 cycles 

-55 to 105°C, 25 cycles 
HOT. 1 wk 

( I.. S0 2 , N0 2 . H 2 S. 1 wk 

2&65°C, 80-98% RH, 
2wk 

lOOVdc, 1 GQ 
lOOVac < 0.5 mA 



* Highly accelerated stress testing 

' Tests performer) sequentially on me same sample ol 6 

contacts on 200-micrometer and lOO-micrometer pitches 
were successfully used in other exercises." 

Extensibility of DTAB 

The outer-lead pitch chosen for the area array designs ( 1 .625 
mm or 0.064 inch ) was driven by the need to maintain com- 
patibility with relatively coarse-pitch printed circuit boards. 
As printed circuit technology improves, the pitch can be 
easily shrunk to as little as 0.635 mm (0.025 inch), which will 
produce a 1000-Iead package of roughly the same size as 
DTAB-432. In the peripheral version, prototypes have been 
successfully fabricated and tested with outer-lead pitches as 
low as 0.1 mm (0.004 inch), The resulting packages were 
only about 3.5 mm larger than the chip itself. 

Two major hurdles have been hampering the successful de- 
velopment of a commercially viable, cost effective multichip 
module technology. One issue is the inability to lest and 
bum in the component ICs before to assembling the multi- 
chip module. The second is the difficulty of replacing faulty 
components on a finished assembly. Without an acceptable 
solution to these two problems, it is difficult to envision a 
multichip module technology with a high enough yield to 
make it commercially competitive. 

The prev ailing methods of assembling ICs on multichip mod- 
ules (wire bonding. TAB. and solder bumps) are at the core 
of these difficulties. Wire bonding and solder bumps require 
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Fig. 20. 272-lead peripheral DTAB package. 

obtaining bare chips from various IC manufacturers, but the 
techniques for testing and burning in bare chips are not yet 
available. TAB does provide a potential solution to the test 
and burn-in issue, but. like the other two methods, is not 
reworkable. 

The DTAB concept presents a clear and easy solution for 
both test/burn-in and rework. Therefore, in addition to being 
a Competitive single-chip packaging approach, it represents 
a very promising nuiltichip moduli' enabling technology and 
a migratory path from single-chip to multichip assembly. 

Conclusions 

Demountable TAB (DTAB) is a new packaging technology 
that capitalizes on TAB's advantages while avoiding its main 
drawbacks, The DTAB concept generates significant benefits 
in the areas of system design, manufacturing, and support. 
Electrically and thermally, the DTAB package compares 
very favorably with any existing high-performance package. 
Its performance has been proven at clock frequencies up to 
125 MHz and power dissipations up to 40 W. 

DTAB packages were fabricated and tested with outer- 
lead area-array pilches of 1.6 mm and peripheral pitches 
of 0.4 mm, 0.2 mm, and 0.1 mm. The area-array version has 
successfully passed formal qualification. 

The DTAB concept offers not only a competitive single-chip 
package, but also an enabling technology for mullichip 
modules. 
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The EISA Standard for the HP 9000 
Series 700 Workstations 



The EISA interface on the HP 9000 Series 700 workstations provides a high- 
performance, expandable architecture that allows peripherals using different 
I/O standards to communicate with the system on the same I/O bus. 

by Vicente V. Cavanna and Christopher S. Liu 



The Extended Industry Standard Arohilecture (EISA) was 
selected for the HP 9000 Series 700 workstations to meet the 
I/O system performance and expandability needs of HP cus- 
tomers. The I/O system provides the communication link 
between the workstation and its external peripherals. Many 
of today's computer applications require a high-performance 
I/O link. EISA complements the performance of the Series 
700 processors, and provides this high-performance path. 

EISA is a descendant of the Industry Standard Architecture 
(ISA). 1 More address lines, data lines, and control signals 
were added for EISA to enhance performance. EISA pro- 
vides separate 32-bit address and 32-bit data buses, supports 
multiple bus masters efficiently, provides for enhanced DMA 
functionality, and defines a synchronous data transfer proto- 
col for burst cycles, An EISA configuration utility allows au- 
tomatic configuration of add-on I/O cards installed in the 
computer. A technical summary' of the major EISA features 
includes: 

Full 32-hit memory address bus 

Full 16-bit I/O address bus 

Multilevel, round-robin centralized arbitration 

33-Mbyte/s burst rate (four-byte — one double-word — transfer 

per EISA clock cycle operating at 8.33 MHz) 

Efficient support of multiple, intelligent bus masters 

Enhanced DMA support for high-performance, inexpensive 

DMA devices 

12 programmable edge-triggered or level-triggered interrupt 
lines 

DMA controller that has: 

0 Four cycle types (ISA-compatible, Type-A, Type-B, and 
Type-C) 

c Three transfer modes (single, block, and demand) 

Programmable transfer sizes (8, Hi, and 32 hits) 
o Channel modes (autoiniiializing. buffer-chaining, and 

ring-buffer) 
Programmable interval timers 
Vectored interrupt controller 
Automatic data bus Iranslation that can handle: 

Mismatched size (8, 1(5. and 32 bits) 
5 Mismatched cycle type (system. ISA, EISA, burst, and 

nonburst) 

Arbitrary' atomic transactions via LOCK mechanism 
Automatic card configuration 
Full compatibility with ISA cards. 

Typically, there are many basic I/O capabilities thai are 
built-in features of a computer. Many customers have unique 



requirements, so their needs may require additional I/O ca- 
pabilities. The EISA I/O expansion bus gives customers the 
flexibility to add functionality to their computers. 

Why IIP Chose EISA 

The primary I/O bus objective for all of the new IIP work- 
stations is to converge rapidly to a single industry-standard 
I/O expansion bus. HP selected EISA for the HP 0000 Series 
400 and Series 700 workstation families because it is an 
industry-standard, high-performance bus that meets the 
needs of HP customers and the goal of a single bus for new 
workstation platforms. 

EISA was built upon the ISA standard to provide compatibil- 
ity with ISA cards. EISA is an electrical and mechanical 
superset of ISA which allows customers to tap into the vast 
array of ISA products. An industry -standard I/O bus like 
EISA allows HP customers to plug any investment of ISA or 
EISA cards into their EISA-based workstations, and be con- 
fident the cards will work given that the correct software 
drivers are available. 
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Fig. 1. System block diagram offtlfl HP 8000 Series 700 workstation 
I/O subsystem, 
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HP cannot realistically design workstations to fill every mar- 
ket niche. Thus, some HP customers will take advantage of 
having EISA to customize their own workstation applica- 
tions. In addition, business partners like system integrators, 
complementary-hardware vendors, and complementary- 
software vendors are willing to create solutions for HP cus- 
tomers. Typically, these solution creators are attracted to an 
open-bus architecture with a comprehensive set of hard- 
ware and software development tools. Many development 
tools are available through third-party ISA and EISA ven- 
dors. HP provides the EISA I/O services and routines to be 
used by all HP-UX* interface drivers written for ISA and 
EISA cards. An EISA open-systems toolkit is available from 
HP for developing drivers. 

EISA Adapter 

The EISA adapter resides, along with the built-in I/O devices 
and graphics, on a 100-Mbyte/s to 132-Mbyte/s system bust 
(see Fig. 1 ). The system bus is a nonmultiplexed. 32-bit- 
address. 32-bit-data synchronous bus running at between 
25 MHz and 3:3 MHz. This bus is one of the ports into the 
memory and system bus controller. 2 Communication on the 
system bus is always between the memory and system bus 
controller and another bus entity. No direct communication 
between other pairs of bus entities is allowed at the present 
time. 

The EISA adapter connects the EISA bus to the system bus. 
The EISA adapter contains an Intel 82350 EISA chipset along 
with logic to interface this chipset, which was designed to 
interface to an Intel486 bus. to the system bus (see Fig. 2). 
The Intel chipset includes three chips: the 82352 EISA bus 
buffer, the 82357 integrated system peripheral, and the 
82358 EISA bus controller. 

The EISA adapter contains byte-swapping logic to overcome 
some of the problems associated with connecting a big- 
endian system to a little-endian system. Tt The byte-swapping 
logic ensures thai byte arrays arc stored in memory in the 
same order (i.e., the same byte addresses) on both sides of 
the interface. The EISA adapter also contains an address 
translation mechanism, known as the I/O map, which maps 
an EISA page into a physical page in host system memory. 

The EISA adapter also contains logic to scramble the por- 
tion of the EISA I/O address space thai is used by the ISA 
expansion cards to allow the host's page-based access 
protection mechanism to be applied to protecting the ISA 
expansion cards from unauthorized access. This scrambling 
is done in the EISA address bus buffers. 

The Intel 82350 EISA chipset contains all the functionality of 
a standard PC system. The chipset handles translations be- 
tween the various EISA communicating entities so that the 
new EISA cards and the old ISA cards can communicate 
without knowing each other's protocol. The chipset has 
shared system resources such as DMA controllers, timer/ 
counters, interrupt controllers, and arbitration controllers. 

t The existing memory I/O controller limits throughput to two-thuds of the maximum bus 

t In a little-endian system the LSB has the lowest address In a big-endian system the MSB 
has the lowest address 



Host View of EISA Memory and I/O Space 

The host CPU can do byte-level accesses to EISA. The sys- 
tem supports arbitrary address alignment of data transfers, 
but the CPU always does aligned transfers to EISA. This 
means that the address of data being sent to EISA must be a 
multiple of the size (in bytes) of the data being transferred. 

Fig. 3 shows the addresses for EISA memory and the I/O 
space as seen from the host. The host uses addresses be- 
tween FC00 0000 and FFBF FFFF to access EISA and ISA 
memory and I/O and the internal registers of the EISA 
adapter. Addresses FC00 0000 through FC07 FFFF are used 
to access EISA I/O space and the EISA adapters. The remain- 
ing addresses ( FC08 0000 to FFBF FFFF) are used to access 
EISA memory. The host uses a portion of its EISA memory 
address range (FC10 0000 through FC4F FFFF) to access 
the I/O map entries. These address range restrictions are not 
a problem since the location of memory on the EISA cards is 
usually configurable. 

Addresses FCOO 0000 through FC00 FFFF in the host's EISA 
I/O space are reserved for EISA expansion cards and EISA 
system registers. This address range is sufficient for access- 
ing any location in EISA's 16-bit address space, including ISA 
expansion cards. Howev er, to access ISA cards via this ad- 
dress range is not allowed because the ISA access protec- 
tion mechanism (described below) would be compromised. 
The hardware will return garbage on a read operation or 
ignore the transaction on a write. 

The ISA expansion cards must be accessed via the host 
address range FC02 0000 through FC07 FFFF. This address 
range is mapped in a special way into the 16-bit addresses 
0100 through 03FF of the EISA I/O space for exclusive use 
by the ISA expansion cards. This special mapping is done to 
avoid conflict with old ISA cards and to provide card-level 
access protection for the ISA expansion cards by using the 
system's page-level (4K bytes per page) access protection 
scheme. 

System Bus 
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Fig. 2. Hock diagram of the EISA adapter 
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Hosl Address 


Description 


Size 


OxFFFF 


FFFF 


PA-RISC Broadcast. Miscellaneous I/O Space 


4M Bytes 


OxFFCO 


0000 






OxFFBF 


FFFF 


EISA Memory (Window into EISA Address Range 0x0100 0000 through 0x03BF 


44M Bytes 


OxFDOO 


0000 


FFFFI 





OxFCFF 


FFFF 


EISA or ISA Memory (Window into 0x0050 0000 through OxOOFF FFFF) 


11M8ytes 


0xFC5O 


0000 






0xFC4F 


FFFF 


Addresses in this range address the data in the I/O map. Host uses these 


4M Bytes 






locations to program the I/O map. One entry per page, all page offsets alias to 




OxFCIO 


0000 


the same map entry. 




OxFCOF 


FFFF 


EISA or ISA Memory (Window into 0x0008 0000 through OxOOOF FFFFI 


512K 8ytes 


OxFCOB 


0000 







OxFC07 


FFFF 


Standard and Nonstandard Page-Aligned ISA I/O space 


384K Bytes 


OxFC02 


0000 






OxFCOl 


FFFF 


EISA Interrupt Acknowledge Space 


32K Bytes 


OxFCOl 


8000 


Use address OxFCOl FOOO 




OxFCOl 


7FFF 


EISA Adapter Registers 


32K Bytes 


OxFCOl 


0000 






OxFCOO 


FFFF 


EISA Slot-Dependent I/O Space and EISA System Registers 


64K Bytes 


OxFCOO 


0000 






OxFBFF 


I I LI 

rrrr 


PA-RISC Functions 


192M Bytes 


Ox FOOD 


0000 






OxEFFF 


FFFF 


PA-RISC Defined 


3840M Bytes 


OxOOOO 


0000 








■ 


Locations used to access EISA address space. 





-© 

-© 
.© 

-® 



®-® 
© 



Locations used to map to EISA memory (see Fig. 4|. 
EISA I/O space. 



The protection scheme works by mapping each of the 96 
sets of eighl consecutive locations available for an ISA ex- 
pansion card space lo the first eight bytes of a 4K-byte host 
page. The assumption is that most ISA expansion cards use 
registers in multiples of eight bytes. If a card needs more than 
eight registers. I hen the card will need to be allocated more 
than one host page. This mapping is not done for the EISA 
motherboard devices (EISA sloi (I) because the registers are 
scattered all over the address range. This mapping is also 
not done for I he oilier EISA slot -specific addresses because 
they naturally fall on page boundaries. 



Fig. 3. Host's address map 

EISA View of the Host Memory- 
EISA devices can do byte accesses to host memory with 
arbitrary address alignment. These devices see the host 
memory through an address translation mechanism known 
as the I/O map located at the EISA memory address range 
0010 0001) through 00-1F FFFF (see Fig. 1). This map is a IK 
array of 20-bit entries. The low-order 12 address bits of the 
EISA memory address specify the offset within a physical 
page in the host memory. The next 10 bits .select one of IK 
entries in lite I/O map. Each map entry is a 20-bit address 



EISA Address 


Description 


Size 


OxFFFF 


FFFF 


Local EISA Memory 


4036M Bytes 


0x03C0 


0000 






Ox03BF 


FFFF 


EISA Memory (Visible to Host through Host Address OxFDOO 0000 through 
OxFFBF FFFF) 


44M Bytes 


0x0100 


0000 




OxOOFF 


FFFF 


EISA or ISA Memory (Visible to Host through Host Address 0xFC50 0000 


11M Bytes 


0x0050 


0000 


through OxFCFF FFFF) 




0x004F 


FFFF 


EISA devices use this range to address the I/O map. which causes a transla- 
tion in the address to a host memory access. The lower 12 address bits are 
not translated (i.e., pass straight through to host memory), and the next 10 bits 
access IK entries in the 1/0 map which are translated to a 20-bit page number 


4M Byles 


0x0010 


0000 


in host memory. 




OxOOOF 


FFFF 


EISA or ISA Memory (Visible to Host through Host Address OxFCOB 000 


51 2K Bytes 


0x0008 


0000 


through OxFCOF FFFF) 




0x0007 


FFFF 


Local EISA or ISA Memory 


512K Bytes 


OxOOOO 


0000 
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EISA locations that map to host address space. 

Specific EISA memory locations associated with host locations shown in 

Fig. 3. 



Fig. 4. EISAs addres 
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that points to the corresponding physical page number in 
host memory (see Fig. 5). This mechanism allows scatter/ 
gather accesses to host memory. That is. the driver can map 
a series of noncontiguous pages in system memory to contig- 
uous pages in EISA memory so that a single EISA DMA trans- 
fer can transfer multiple system pages. This eliminates some 
of the need for DMA chaining (for large transfers) and its 
associated penalties ( interrupt overhead, reprogramming 
DMA, etc.). 

The address ranges shown as local EISA memory in Fig. 4 
cannot be seen by the host. 

A Note about EISA I/O Space 

The ISA bus I/O space has always been 64K bytes (16 ad- 
dress lines), but the I/O address range is arbitrarily limited 
to 1024 locations. In addition, the first 256 bytes are reserved 
for devices on the EISA motherboard, with an address range 
(KMX) through 00FF (LA[9:8] both equal to zero).f This leaves 
768 bytes (96 sets ofS) for all of the expansion cards on the 
bus. with an address range 0100 through 03FF. This allows 
the old ISA expansion cards to ignore (and they do) all but 
the least -significant 10 bits of the 16-bit address. 

To avoid conflict with the old ISA expansion cards, the new 
EISA expansion cards can only use addresses such t hat the 
least-significant 10 bits range between 0000 and 00FF, and 
LA[9:8| must both be zeroes. Thus, the address range corre- 
sponding to each EISA slot is fragmented by the address 
ranges that alias to ISA addresses. For example, in Fig. 6 in 
the address range for slot I (1000 to 1FFF), four suhacldress 
ranges alias to 0100 to 03FF. The old ISA expansion cards 
think the EISA slot-dependent I/O addresses are motherboard 
addresses, since they do not look at the upper address bits. 

The EISA expansion cards decode the full 10 address bits, 
and have available 1024 locations "sparsely populating" each 
EISA slot, A system can support up to 16 EISA slots. 

Byte Swapping 

In the PA-RISC' architecture of Series 700 workstations, the 
most -significant byte is at the lower address ( big endian), 
and in EISA, the most -significant byte is al the upper address 
(little endian). 

t LA means latchable address and LA|9 81 are 1x1$ 8 and 8 of trie LA bus 
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Fig. 6. A portion of the EISA lfi-bit I/O address map. 

Byte swapping hardware, which is provided on the EISA 
adapter board, ensures that byte arrays are stored in mem- 
ory in the same order on both sides of the adapter. This 
makes it easy for devices like disks to be connected to the 
built-in SCSI port or the EISA SCSI card, and the data to be 
inierchangeable without needing to know where the disk- 
resided when it was read from or written to. 

However, because of this swapping, any multibyte com- 
mands Written lo EISA devices must be prcswapped by soft- 
ware. Similarly, any multibyte data structures placed in host 
memory to communicate With intelligenl conlrollers on 
EISA must be preswapped. 

Arbitration 

Two arbiters exist in the system, the EISA arbiter and the 
System arbiter. The EISA arbiter was designed with the para- 
digm that il is the sole arbiter and controls all resources in 
the path to memory. The consequence of this decision is that 
the EISA arbiter commits irrevocably to its highest-priority 
client before it knows if it has all the resources it. needs to 
access memory. 

If the system arbiter operated the same way we could have a 
deadlock. The system arbiter could be designed to back ofr 
in a potential deadlock situation. However, for simplicity, in 
this version of the PA-RISC workstation, the system arbiter 
simply gives the EISA arbiter complete control over all re- 
sources in the path to memory and temporarily becomes a 
client lo the EISA arbiter. 

The system arbiter uses the CPU slot in the EISA arbiters 
arbitration hierarchy. Once the system arbiter gains control 
it uses its arbitration algorithm to share its slot among its 
clients. I he EISA arbiter being one such client. Thus, only 
one arbiter is in control of all resources at. any given time. 
The arbiters hand control over to each other amicably. 



Kin. 5. Vldress mapping, viu 1 1 1 • - I/O map 
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Conclusion 

The expandable architecture described here provides the 

high-performance characteristics of I he EISA standard and a 
communication link to peripherals using different I/O stan- 
dards. The article on page 83 describes in detail the hard- 
ware design for the current set of EISA I/O cards developed 
for the IIP 9000 Series 700 workstal ions. The software design 
for the EISA SCSI card is descrihed on page 97. 
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EISA Cards for the HP 9000 Series 
700 Workstations 



The EISA specification's high-performance, burst-cycle protocol for data 
transfer is provided on the Series 700 EISA cards through the 
implementation of DMA and EISA bus master interfaces. 



by David S. Clark, Andrea C. Lantz, Christopher S. Liu. Thomas E. Parker, and Joseph H. Steinmetz 



Besides providing EISA capabilities to the HP 9000 Series 7(X) 
workstations, the EISA adapter described on page 79 pro- 
vides the facilities for connecting several EISA cards with 
different front-end I/O protocols to the Series 71)0 I/O bus. At 
the time of system release four IIP EISA cards were available 
for the HP 9000 Series 700: an EISA LAN card, an EISA HP-IB 
card, an EISA SCSI card, and an EISA PSI (programmable 
serial interface) card (see Fig. 1). 

Each project team working on the EISA cards for the 
Series 700 had its own project-specific objectives, but the 
common objectives shared by all were to: 
Provide high-performance add-on I/O (EISA) solutions for 
the Series 700 workstations 

Design low-cost EISA solutions without compromising 

quality, reliability, and performance 

Meet all workstation development milestones. 

The EISA specification was relatively new at the time we 
started investigating and proposing different architectures 
for I he four EISA cards described here. 



EISA specifies a burst-cycle (8-. 16-, or 32-bit data transfers) 
protocol for transferring data. There are two primary meth- 
ods by which an EISA card can take advantage of the burst 
cycles: through an EISA bus mastert or DMA. During our 
investigation we found very few VLSI and ASK' chips avail- 
able from vendors that had an EISA bus master or DMA 
solution integrated into a chip. We looked at all of the avail- 
able and proposed chips and decided that they did not fit 
our requirements. The decision was made to implement the 
EISA bus master and DMA interfaces on our EISA cards 
with discrete logic using PAL and TTL devices. In addition, 
the EISA memory and I/O slave interfaces on our cards are 
implemented with discrete logic. 

The EISA LAN and EISA SCSI cards use a technique called a 
bus gasket ( described below ) to implement an EISA bus 
master interface. Both cards take advantage of the power of 
their respective I'rontplane controller by adding logic between 
it and the EISA backplane to translate the controller signals 

T A bus master transfers data to or from mam memory using addresses under its control 
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Fig. 2. IVpical architecture for an I/O expansion card. 

to EISA signals. The incremental cost to Implement a bus 
master gasket circuit for these I wo cards is low compared to 
adding a separate VLSI bus master chip. 

The EISA HP-IB and EISA PSI cards implement an EISA DMA 
interface. The EISA HP-IB card has a fronlplane controller 
geared to DMA-type transfers, so naturally the DMA inter- 
face is the best method for this card. On the other hand, the 
EISA PSI card can use either method. The DMA interface 
was selected for the EISA PSI card because of its relatively 
Simpler circuitry (compared to a bus master) and the nature 
of the card's protocol data structures. 

The Bus Gasket 

A bus gasket is an interface that combines a noncompatible 
processor bus wild an expansion I/O bus (e.g., a Motorola 
(»8000 microprocessor with EISA). The bus gasket handles all 
synchronization, pipelining, and control signal translations 
between the processor and the expansion I/O bus. 

The processor on an add-on I/O card may be a microproces- 
sor or an intelligent link-controller coprocessor. Examples 
of intelligent link controllers include the Intel 82596CA LAN 
controller and the NCR 63C710 SCSI controller. From the 
host system's point of view, a bus gasket interface appears 
as a standard bus master. From the on-card processor's 
point of view, the system memory appears as a local mem- 
ory resource to be used as it would any Other memory re- 
source. The objectiv es of a bus gasket design are reduced 
complexity, reduced cost, increased performance, and 
increased utilization of the on-card processor. 

The standard architecture of an add-on I/O card consists of 
fronlplane, midplane, and backplane circuitry ( s cc Fig. 2). 
The Irontplane is the link-specific electrical interface and is 
defined by its standard. The midplane consists of a processor 
or a buffer that matches the synchronous nature of the back- 
plane to the asynchronous bursty nature of the fronlplane. 
And finally. I he backplane is the interface to I he expansion 
I/O bus. 

When archil ecting a card for EISA, one of two data-transfer 
methods is typically chosen for high-performance cards: bus 
master or DMA. Many factors determine which to use for a 
specific card, but if the card needs to source addresses for 
system memory' accesses and if the data transfer is of a scat- 
ter/gather nature, the bus master is generally the choice. If 
the data is more block-oriented and sequential in system 
memory. DMA is a more practical and low-cost solution. 

When the choice is bus master, the cost can be high because 
of the increased complexity. A non-VLSI implementation of a 
bus master can be cost and board-space prohibitive, and an 
off-the-shelf interface chip can be expensiv e and generally 
requires a dedicated microprocessor to service it. However, 
if the card already uses a powerful link-controller coproces- 
sor, its power can be harnessed to provide both cost and 
performance benefits. 



The bus gasket, which is the logic that translates controller 
signals to EISA signals, provides the following benefits: 
1 Lower Cost. Bus gaskets can be cheaper than other imple- 
mentations of a bus master interface. Bus master chips are 
available to create a "friendly" interface between the card 
midplane hardware and the bus backplane. However, be- 
cause they are relatively dumb bus master controllers, these 
chips require an on-card dedicated microprocessor to control 
them. The additional complexity and cost of implementing 
one of these interfaces can be prohibitive in a cost-sensitive 
application. 

Belter Use of the Link Controller. One of the primary bene- 
fits of bus gaskets is I he ability t o harness I he power of an 
on-card link-controller coproc essor. The link-controller co- 
processor can operate out of (host) system memory via 
EISA. On two of the EISA add-on cards, we require a bus 
master interface because the link-controller coprocessor 
follows command chains and data buffer chains that reside 
in system memory. The link-controller coprocessors used in 
the HP EISA 802.3 LAN and HP EISA SCSI cards are power- 
ful protocol-specific processors. We wanted to make- use of 
lite power of these complex processors. If we had isolated 
them from EISA via a DMA interface or some other simple 
interface, we would have lost much of the power of the 
cards to manipulate Structures in system memory. 
Less Complexity. The bus gasket reduces the complexity of 
the card by removing the need to have a microprocessor 
and associated firmware on the card. Also, since we are 
already using the bus arbitration and control mechanisms of 
the on-card link-controller coprocessor, the backplane bus 
master hardware can be greatly reduced. Some complexity 
does exist, however, inside the bus gasket itself. 

Technical Hurdles 

Two primary technical hurdles typically get in the way of 
Implementing a bus gasket. The first problem is the differ- 
ence in the way in which the link controller and the EISA 
backplane handle address and data bus cycles. In EISA 
addresses and data are pipelined — that is, they overlap — 
because EISA requires a valid (correct ) address to lie avail- 
able one-half to one-and-one-half BCLK (clock) cycles before 
valid data can be captured by the coprocessor (see Fig. 3). 
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-< Data! > 
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Fig. 3. Simplified timing diagram (if EISA pipelining of address and 
(lata (luring read and write burst transfers. Note thai the address of 
data 2 must bp valid one-half to one-and-one-half BCLK cycles before 
data 2 becomes valid for capture. 
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The second problem is that the link controller's clock might 
be incompatible with the backplane clock. Typically, the 
clock rate of the link-controller coprocessor is required to 
be at least twice the rate of the backplane clock, and in the 
case of the EISA bus. its clock can be suspended to stretch 
cycles This might cause some problems for a coprocessor 
that requires strict clock tuning. 

To solve these problems, some logic must be added to the 
card to synchronize the coprocessor's bus cycles, data, and 
addresses to the backplane bus. This logic is embodied in 
the bus gasket 

For I he EISA bus gasket designs, pipelining was the major 
hurdle. The IAN controller used for the EISA LAN card is 
based on the Intel486 microprocessor which runs straight 
T1-T2 address/data cycles, t Without some additional logic 
there could be a deadlock situation when trying to run 
straight read burst cycles on EISA efficiently. One alternative 
would be always to insert an extra bus cycle after each read 
operation. This would give the IAN controller the chance to 
capture the data presented to it by the system in the Current 
cycle, and allow it time to set up the transaction address for 
the next transfer. With this method, however, we could 1101 
make efficient use of EISA during mastered burst readsft 
from memory and perform single-cycle burst transfers. Also, 
reads from memory would take three cycles. 

Two methods can be used to solve this problem. The first is 
to use the processor's hurst (cache-fill) mode. The second 
method is to implement a way of predicting the next address 
and verifying its correctness after the next address is pre- 
sented by the controller. We chose the second method for 
performance reasons. 

The HP EISA LAN Card 

The HP EISA IAN card implements a bus master gasket de- 
sign (Fig. 4). All mastered transfers generated by the card are 
initiated by the Intel 82596CA LAN controller. The 82596CA 

t A data address is available at lime Tl followed by data at lima T2 

I ' Mastered burst reads are 8-. I6-. 01 32-bit transfers from host memory when a device is bus 
master 



performs transfers in the form of Intel4S6-compatible micro- 
processor accesses. These accesses are transformed into 
EISA transactions by the bus master gasket circuits. The 
card performs all mastered transfers on the EISA bus as 
32-bit burst memory accesses. 

The 82596CA is driven by a 33.3-MHz oscillator. Since the 
EISA clock (BCLK) runs at 8.33 MHz. which is four times 
slower than the 8259GCA's clock, a circuit on the card called 
the master controller synchronizes the data and address 
buses of the LAN controller and EISA using a signal called 
Rdy_N. 

EISA read and write burst cycles are basically one BCLX pe- 
riod, but as shown in Fig. S the address can potentially over- 
lap the previous or next transfer cycle by one-half a BCLK 
cycle. This is because the address contained on lines LA[31.2] 
must be valid on the EISA bus relative Co the falling edge of 
BCLK and before the rising edge of the next BCLK cycle that 
starts the data transfer. Likewise, the subsequent transfer 
will overlap by one-half cycle as it prepares the LA|31:2| bus 
for its correct transfer address. 

This poses a problem during mastered burst reads because 
EISA burst timing requires that LA|31:2] for the next read 
transfer be valid before the data from the Current read ac- 
cess is available (read returned data on EISA is not guaran- 
teed to be valid until the rising edge of BCLK). This is not a 
problem for burst writes because the coprocessor does not 
have to wait for incoming data. 

To handle the problem for mastered reads, a scheme called 
address prediction is used to compute the addresses the 
82590CA will use during burst read transfers. A circuit on 
the card called the address generator (see Fig. 5) contains 
logic to predict the next address, drive the address onto the 
EISA bus, and verify t hat the address is correct from the 
previous data transfer. 

Fig. G shows a snapshot of I he timing and signals associated 
With this address prediction scheme for a burst read. At \ 
the predicted address 5 for the current transfer is driven 
onto the LA|31:2| bus lines and the 82S96CA IAN controller is 



Bus Gasket 



LAN 



Control 
Signals 




Master 
Controller 



Address 
Generator 
(Predictor/ 

Verifierl 




5 EISA Control Signals 



5 EISA Control Signals 







-r r 

. 30 LA |3121 (EISA Address) 


M 


BCLK (EISA Clock) 



32 (Dotal 



EISA 
Bus 



Fig. 4. Block diagram of the HP 

eisa lan card. 



Intel 
B2596CA 

LAN 
Controller 



Data 
Latches 




© Copr. 1949-1998 Hewlett-Packard Co. 



Ueremlx-r 1 111 1:2 I Irwletl-Parkard Journal 85 




1 From Intel 82596CA LAN Controller 

2 From Master Controller 

3 From EISA Bus 

Fig. 5. Address generator fur the HP EISA LAN card. 

preparing lo capture the data from t ho previous read trans- Also during this time the predictor computes the next ad- 
fer. Al S . on the rising edge of BCLK. the data from the pre- dress (address 5). At •• the S25!K>C'A drives Ihe current 
vious transfer at address 4 is captured by Ihe card. If Ihe transfer address onto ils lines. From this point on. the verify, 

predicted address of Ihe previous transfer compares with the prediction, and Rdy_N operations continue, starting wilh ihe 
address produced by the 82596CA (in this case 4), the verification address being 5 and the predicted address 6. 

825flfi("'A is stepped by pulsing the Rdv_N signal for 30 ns. 
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IT a predicted address does not match the 8259GCA address, 
appropriate action is taken by the master controller and the 
correct transaction is executed. A predicted address miss 
can cause the loss of one to three BCLK cycles depending on 
the types of predictor misses occurring. 

Generating Addresses 

Tin- address predictor and verifier logic shown in Fig. 5 gen- 
erates the next address based on the current transfer ad- 
dress during read bursts. The predi<tor is loaded with the 
start address at the beginning of a data transfer Initiated by 
the 82596CA LAN controller. Subsequent predicted ad- 
dresses are generated by the predictor incrementing the 
current address for each transfer. Each predicted address is 
placed on the LA address bus before the S2596CA is able to 
generate the actual address. Standard EISA read transfers 
and standard and burst write cycles do not require address 
prediction. 

At the start of a standard or burst read or write transfer 
sequence, the 82596CA loads the predictor with the initial 
transfer address. The first transfer cycle after being granted 
the bus is always a standard EISA transfer. A standard trans- 
fer must precede ail burst transfer sequences. During stan- 
dard read transfers, the address from the 82596CA (A[31:2|) is 
lalched and driv en as LA[31:2] on Ihe EISA bus. Addresses 
generated during writes are copied directly from ihe address 
bus of the S2596CA and latched and not driven onto the 
EISA bus until the appropriate EISA cycle and the presence 
of the Rdy_N signal. 

After the system has granted the bus lo the card and the 
82596GA asserts the signal Ihat indicates thai the first ad- 
dress and the direction signal (W/R) are valid on its pins, the 
first address cyc le begins. If Ihe 82596CA Is starting a write, 
the predictor and v erifier are disabled. 

If the direction of transfer is read, the predictor and latching 
registets are loaded with the address present on A|31:2] and 
the LA|31.2| bus is actively driven on the falling edge of BCLK 
just before the EISA Stan* signal begins the address cycle. In 
the next cycle (the data cycle), read data will be valid on the 
rising edge of BCLK at Ihe end of I he cycle. Also during this 
data cycle, the address for Ihe next transfer must be valid. 

After Ihe first transfer, standard transfers and burst writes 
proceed as normal. However, burst reads require each sub- 
sequent address to be predicted because EISA requires a 
lead time for addresses. 

The combined address multiplexer and latch shown in Fig. 5 
are used to select one of three address sources to provide 
the next address to LA|9:2|. the address or the transfer within 
a 1 K byte page.t The three sources are A|9:2| from the 
82596CA. the predicted next address PreAd|9:2|. and the wrile 
address source WA|9:2|. Three sources are required because 
to provide the correct address on LA[9:2], different values are 
required depending on the type of transfer being done and 
the current phase being executed within a transfer. 

t EISA restriction id ensure that a memory module can he as small as I K tiytes 



Generating MSBurst* 

MSBurst* is a tristate EISA signal driven by a card that wants 
to perform mastered burst transfers. MSBurst* must be as- 
serted whenever there is a burst cycle address being driven 
on LA[31 2| and deasserted during the last burst transfer cycle. 

MSBurst* is generated in the address predictor/verifier block 
because the result of the address verification is directly re- 
sponsible for whether the next cycle can be a burst or not. 
To start a burst series. Ihe SLBurst* signal from the slave 
(host memory ) is sampled on the rising edge of BCLK at the 
beginning of the second cycle of a standard transfer. If 
SLBurst* is asserted, which indicates that the slave can burst, 
MSBurst* is asserted on the subsequent falling edge of BCLK as 
the address for the burst cycle is driven onto LA(312) (see 
Fig. 7). 

Starting with the first transfer and continuing with each 
burst cycle, the page address A|31:10) of the next transfer is 
compared with the page address of the current transfer 
| SLA[31:10] in Fig. 5). If they do not match. MSBurst* will be 
deasserted on the falling edge of BCLK during the next burst 
cycle as the new page address is placetl on Ihe LA bus. This 
will begin a new standard transfer if the card still owns the 
EISA bus. 

If during burst transfers the card is preempted by the sys- 
tem, MSBurst* will be deasserted on the falling edge of BCLK 
during the last burst transfer. The transfers will cease when 
the 82596CA deasserts Holdtt in response to the preemption. 
The master controller will force the deasscrtion of MSBurst* 
as it detects the deasscrtion of Hold. I Ihder these conditions, 
the deasscrtion of MSBurst* will not necessarily occur in Ihe 
current cycle. There is a programmable timeoul that will 
determine how much data the card will continue Iransfer- 
ring after preemption. 

The HP EISA SCSI Card 

The IIP EISA SCSI card design is based on the idea of mini- 
mizing Ihe component count and using as much of the proto- 
col and features of the SCSI controller as possible. The bus 

tt Hold is a sirjnal that requests access 10 Ihe local bus 
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master gasket approach described earlier is used to com- 
bine two different domains together with logic to translate 
signals from one to the other while meeting the functional 
and timing requirements of both. 

In this case the two domains are EISA and the bus interface 
logic of the NCR 53C710 SCSI controller chip, which is con- 
figured to function as a 680-10 microprocessor synchronous 
bus (see Fig. 8). Some of the differences between the SCSI 
controller and EISA that are handled by the bus gasket logic- 
are given in Table I. 

Table 1 

Signal Differences Between EISA 
and the NCR 53C710 SCSI Controller Chip 



EISA 

A[31:2l- Address bits 

BE|3:0] - Indicates which 
bytes are valid at the cur- 
rent address 

Pipelined address 

Bus Control Logic 

Start' - Indicates address 
of current I/O transaction 

EXRDY - Indicates wait 
state (I/O transaction is 
done at the end of the 
wait state ) 

EX32 - Indicates 32-bil- 
wide data path 



NCR 53C710 

A|31:0] - Address bits 

SIZ(0:1| - Indicates data 
width at the c urrent address 

Nonpipelined address 
Bus Control Logic 

TS - I/O transfer start 
(address available) 

TA - Transfer acknowl- 
edge (I/O done) 



The NCR 53C710 SCSI controller was selected for the EISA 
SCSI card mainly for software compatibility with the built-in 
SCSI port of the Series 700 workstations. The EISA SCSI 
soli ware is described in the article on page 97. 

The NCR 53C710 SCSI controller provides several features 
that made it attractive for our implementation. First of all 



the controller runs from two clocks: one for the SCSI proto- 
col and one for the host bus interface, with the synchroniza- 
tion between the two domains occurring inside the chip. 
Working with NCR. we were able to gel an internal bus re- 
quest signal brought out of the chip that deasserts when one- 
transfer is left. Without this signal the EISA burst cycle 
would not have been possible. Finally, the NCR 53C710 pro- 
vides a 10-Mbyte/s 8-bit SCSI, which is an added value over 
the built-in SCSI (5-Mbyte/s) on the workstations. 

Clocking. A clock synchronization scheme is primarily deter- 
mined by the types of interfaces that are being connected 
together. In this case, the EISA bus control signals and data 
are synchronous with the EISA bus clock (BCLK), which un- 
fortunately does not have a fixed frequency nor does it have 
a guaranteed duly cycle from period to period. The 
68040-typc interface of the 53C710 has all of its signals rela- 
tive to its clock. 

The simplest answer lo this problem was to connect the 
EISA clock BCLK to the host bus interface clock so all signals 
would be synchronized wilh the EISA clock. Unfortunately, 
this would not work because of the different protocols and 
the need to burst longer on EISA (for performance reasons) 
than the burst length built into the 53C710. 

Another option was to run the controller from a different 
clock and synchronize it with the EISA clock domain. This 
would not work because the timing losses in the synchro- 
nization would degrade the throughput of the card and not 
allow EISA to operate optimally. Another scheme considered 
was to generate a clock from a phase-locked loop circuit lo 
feed into the 53C710. This was not chosen because the EISA 
clock operates from (> to 8.33 MHz and can stretch, creating 
a nonoptimal duty cycle which could create a problem for 
the phase-locked loop circuit. 

The solution chosen was to create a 2x multiple of the EISA 
clock and present this new clock lo the 53C710. This allows 
the 53C710 to run in nonburst mode ( larger transfer size) 
and be synchronized with the EISA bus. 

Address Generation. Sourcing the EISA address was a major 
area of concent because of the pipelining behavior of the 
EISA bus in burst mode. To provide addresses for reads 
from a SCSI peripheral ( writes to EISA memory), the 
53C710 is allowed to run ahead of the EISA bus while the 
data is latched. This effectively pipelines the nexl address 
from the 53C710. For writes to a SCSI peripheral (reads 
from EISA memory), the 53C710 cannot be allowed to run 
ahead because the EISA data is not valid until the end of the 
clock cycle. For this case, an address predictor (counter) is 
used to first latch then pipeline the EISA address, which will 
always be sequential within any single bus tcnancy.t The 
control logic for the address prediction circuit must also 
know when to increment the address correctly based on 
inputs from the EISA slave being accessed. 

Control Signals. Some of the EISA control signals were not 
very difficult to handle since they had equivalent signals in 
the 53C710 domain. For example the EISA Start' and the 
53C710 TS (transfer start ) signals both indicate the beginning 

Bus lenancv is the length at lime > device is in control of and using the EISA bus 
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of a cycle (or the address phase). However, the EISA MSBurst* 
signal, which is asserted when a card wants to perform mas- 
tered burst transfers, has to be generated because there is 
no 53C710 equivalent. In addition, the MSBurst' signal must 
be deasserted to ensure that the card cannot burst across a 
1Kbyte boundary (per 'he EISA specification), burst across 
the boundary created by the address predictor (memory 
reads only), or burst when the data being transferred is less 
than a double word. 

The address predictor burst boundary is created by the fact 
that the counter only loads the first address of a transfer 
while in the first address phase of the 53C710. Front then on, 
the address is incremented based on the EISA EX32" and 
EXRDY signals and cannot be reloaded. Therefore, when the 
count goes to all ones, the 53C710 must back off. release the 
EISA bus and rearbitrate for the EISA bus. 

The less-than-32-bit boundary is created by the 53C710. For 
example, when the controller is completing a transfer and 
the last transfer is three bytes long, the transfer will be split 
into two-byte and one-byte moves. This will create problems 
for the address prediction logic because it will increment 
the address between these transfers and place the last byte 
in the wrong location. In this situation, the 53C710 will back 
off, release the EISA bus and rearbitrate for the EISA bus. 

EISA and DMA 

A centralized DMA controller is provided on the EISA 
adapter board. This architecture simplifies the design of the 
DMA portion of any add-on DMA card because the complex 
functionality associated with handling DMA transfers is con- 
centrated on the system end of the bus. The DMA controller 
on the EISA adapter board is the master of the DMA devices 
connected to the EISA bus because it services their re- 
quests. A DMA device can be configured in a combination of 
different ways to optimize its performance on EISA. 

DMA devices can be programmed for data transfers using 
one of four DMA cycle types av ailable on EISA. The ISA- 
compatible cycle allows ISA DMA devices to operate with- 
out any hardware or software modifications. These devices 
will have a higher data transfer rale on EISA than ISA as a 
result of EISA's efficient bus arbitration. The Type-A and 
Type-B DMA cycles are EISA modes that allow some ISA 
DMA devices to achieve even higher performance with spe- 
cial software modifications. The burst Type-C DMA cycle is 
the highest-performance EISA DMA cycle, and is only avail- 
able for EISA DMA devices designed specifically to transfer 
data every clock period. 

EISA provides seven ISA-compatible DMA channels. Any 
DMA device on EISA can be assigned to use one of these 
channels. The channels available are channel 0 through 
channel 3 and channel 5 through channel 7. Channel -1 is the 
cascaded channel and is reserved for system use. Also, each 
channel can be programmed to support 8-bit, Hi-bit, or 32-bit 
data transfers. 

The Intel 82357 integrated system peripheral (ISP) provides 
the centralized EISA DMA controller capabilities. The ISP 
resides on I he EISA adapter board. The DM A controller, 
refresh controller, CPU, and bus masters all share the EISA 
bus. A device requesting use of the bus must assert its bus 
request signal to the centralized arbitration controller (also 



contained in the ISP). This arbiter will assert the corre- 
sponding bus grant signal when the bus is available. 

For a DMA device, the bus request signal is DRQ<x>. where x 
represents the DMA channel number. All the DRQ<x> signals 
are fed to the DMA controller, and the DMA controller acts 
as the intermediary by arbitrating for the bus on behalf of 
the DMA channels. When the DMA controller has been 
granted the bus. it asserts the acknowledge signal ( DAK'oo) 
for the appropriate DMA channel. 

Depending on the DMA arbitration sequence selected on 
EISA, the channel priority can be quite different. In the fixed 
DMA priority arbitration sequence, each channel has a dif- 
ferent priority level, with channel 0 being the highest and 
channel 7 the lowest. In the rotating DMA priority arbitra- 
tion sequence, there are two levels of priority. The top level 
uses a four-way rotation to grant bus access sequentially to 
channels ">. 6. and 7. The fourth position is channel 4, but 
this is used as a cascade port for the channels at the lower 
level. The lower level also uses a four-way rotation to select 
sequentially from channels 0, 1 . 2, and 3. 

The DMA controller supports three types of EISA DMA data 
transfer modes: single, block, and demand modes. In the 
single mode, a DMA device will perform one transfer for 
each arbitration cycle. In the block mode, a DMA device will 
perform a block of transfers for each arbitration cycle. In 
the demand mode, a DMA device will perform a group of 
transfers for each arbitration cycle, but it can suspend trans- 
fers temporarily by deasserting its DRQ<x> signal. Block anil 
demand t ransfer modes can be preempted by other devices 
requesting the bus. 

A DMA device is not allowed to add wait slates during an 
EISA DMA data transfer since it is essentially a "third party" 
on the bus monitoring the transaction taking place between 
the bus master and the memory slave. In other words, the 
DMA device must follow the timing of the transfer already 
negotiated between the bus master and the memory slave. 
The bus master in this case happens to be the DMA con- 
troller, which has initiated and is controlling the transfer. 

Two HP-designed EISA add-on cards support the burst 
Type-C DMA cycle using the demand transfer mode. The 
EISA HP-IB and EISA PSI cards both use DMA cycles to 
transfer data because the data structures are more block- 
oriented. Since the DMA controller is centralized and the 
DMA devices do not have to source bus addresses, this 
reduces the complexity of the cards. 

The HP EISA HP-IB Card 

The HP EISA HP-IB card is divided into three functional 
blocks: the EISA interface, the FIFO buffers, and the I IP-IB 
interlace (see Fig. 9). This card has a 10-bit Type-C DMA 
module designed to support the demand transfer mode for 
transferring data between system memory and the 111' 
proprietary 1TL1 HP-IB controller chip. The EISA HP-IB 
card can be programmed to use one of seven DMA channels. 
A 10-bit EISA DMA device can transfer data at rales up to 
10.7 Mbytes/s using burst cycles. 

The ITU controller chip provides the complete logical 
HP-IB interface defined by the IEEE 488 (IEC 02-5) Specifica- 
tion, ll also has a local-host interface that appears as a set of 
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eight addressable registers and provides buffering for out- 
bound and inbound HP-IB data transfers through two inter- 
nal FIFO queues. The local-host interface of this chip is con 
nectcd to the EISA interface and controlled by the local 
DMA slate machine on the EISA IIP-IB raid 

The OUtboUnd direction is defined as data movement from 
system memory to the HP-IB. DMA transfers in this direc- 
tion are performed with mentOIy read eyries and I/O write 
eyries to move data directly from the system to the card. 
Conversely, the inbound direction is defined as data move- 
ment from the HP-IB to system memory. DMA transfers in 
this direction are performed with I/O read cycles and mem- 
ory write cycles to move data directly from the Card to the 
system. 

FIFO Buffer. In the processor-to-peripheral data path, data 
transfers between components of different speeds can 



Fig. 9. Ill' EISA HI'-IB card Modi 
diagram. 



drastically reduce performance. Even with a DMA channel 
between the system and the peripheral, the processor must 
be ready to relinquish the bus on short notice, and go to an 
idle condition. In addition, the data-path reduction from a 
wide bus to a narrower bus will drop the data throughput by 
a significant factor. 

A buffer helps to offload the burden the peripheral places on 
the processor during lcss-than-optimal transactions. The 
data transferred between the system and the peripheral will 
be padded in a first-in, first-out (FIFO) manner. The FIFO 
memory can perform this function. 

To smooth out the DMA transfers, the EISA IIP-IB card has a 
set of FIFO memories that act as an elastic data buffer be- 
tween the faster synchronous F^ISA interface and the slower 
asynchronous HP-IB interface (see Fig. 10). Physically, this 
external FIFO buffer sits between the EISA interlace and 
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the local-host interface of the 1TL1, and supplements the 
two eight -deep, byte- wide inbound and outbound FIFO 
queues in the 1TL1. In addition to the mismatch in bus 
speeds, there is a mismatch in data widths between the 
EISA and HP-IB interfaces on the card. The card has a 16-bit 
data connection ti> EISA, while the HP-IB interface is only 
an 8-bit bus. A direct 8-bit HP-IB interface to EISA cuts the 
EISA data throughput in lialf. when compared to a lfi-lrii bus. 

During the investigation phase of the EISA HP-IB card proj- 
ect, a 32-bit EISA DMA architecture was proposed. However, 
the twofold increase in the complexity and cost to implement 
the FIFO buffer for a 32-bit architecture could not be justi- 
fied lor this card. Thus. I he I(>bit architecture was selected, 
which met the project's performance and cost objectives. 

The FIFO buffer has a 10-bit port on the EISA side and an 
S-bit port on the HP-IB side. Logically, two tU-deep. byte-wide 



FIFO memories appear as a single 64-deep. word-wide FIFO 
buffer to the EISA interface. However, these two FIFO me- 
mories look like least- and most -significant byte data banks 
to the local-host interface. A separate 8-bit bypass port is 
available that allows the system direct I/O slave access to 
the ITLl's control and status registers without having to go 
through the FIFO memories. 

In addition to the local DMA state machine controlling the 
local DMA process between the FIFO buffer and the local- 
host interface of the 1TL1. there are two EISA DMA state 
machines controlling the EISA DMA processes between the 
EISA interface and the FIFO buffer (see Fig. 11). They are 
the outbound EISA DMA state machine and inbound EISA 
DMA state machine. Together, the three DMA state machines 
can handle the concurrent loading and unloading of the 
FIFO buffer. 
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During an outbound DMA transfer, the outbound eisa DMA 
state machine loads data from the eisa interface into the 

FIFO buffer, while the local DMA stale machine unloads the 
data from the FIF< ) buffer to the outbound FIFO queue in 
the ITU. During an inbound DMA transfer, the local DMA 
state machine loads data from the inbound FIFI ) queue in 
the 1TL1 into the FIFO buffer, while the inbound EISA DMA 
state machine unloads the data from the FIFO buffer to the 
EISA interface. The data can only be sent in one direction at 
a time through the FIFO buffer. The appropriate bank of 
tristate buffers is selected to control the direction of the 
data How. In addition, the data width mismatch is resolved 
by packing the HP-IB data bytes into 16-bit words for EISA 
on inbound transfers, and unpacking the lli-hit words from 
EISA into bytes for the HP-IB on outbound transfers. For the 
byte-packing function, the bytes are arranged so that the 
In si land subsequent odd | byte received on an inbound 
transfer is the least-significant byte of the Hi-bit word. For 
the word-unpacking function, the bytes are arranged so thai 
the first (and subsequent odd) byte transmitted on an out- 
bound transfer is the least-significant byte of the l(>bit word. 

On the HP-IB side of the FIF( > buffer, two octal tristate buff- 
ers are used to funnel the outbound data to the ITU HP-IB 
controller chip. This multiplexer, controlled by the local 
DMA state machine, separates the Hi-hit word into two 
bytes by selecting one of the two octal buffers sequentially. 
(The least -significant byte is selected first. ) Also, two octal 
tristate buffers are used as a demultiplexer to move the in- 
bound data bytes from the 1TL1 into the FIFO buffer. One of 
the two buffers is selected (the least-significant byte firsl ) to 
assemble a 16-bil word in (he FIFO buffer. This demultiplexer 
is controlled by the local DMA slale machine. 

On the EISA side of the FIFO buffer, a word-wide tristate 
buffer is used to direcl (he outbound 16-bit words from the 
EISA interface into the FIFO buffer under control of the 
outbound EISA DMA state machine. Also, a word-wide In- 
state buffer is used to direct the inbound Hi-hit words from 
the FIFO buffer to the EISA interface under control of the 
inbound EISA DMA stale machine. 

DMA Transfer Process. For an outbound DMA transfer, the 
EISA outbound DMA request signal (EODRQ) is asserted by 
the outbound EISA DMA state machine when the EISA DMA 
circuitry' is configured and armed on the EISA HP-IB card by 
its software driver and when the FIFO buffer is empty. The 
condition of the FIFO buffer being empty is necessary to opti- 
mize use and performance of EISA and to maximize use of 
the FIFO buffer. 

The card will interrupt the system following the completion 
of the outbound DMA transfer when the EISA icnninal- 
COUnl signal (one of I he DMA control signals going to the 
state machines) is asserted by the syslem (indicating I he 
last EISA DMA cycle) and the FIFI ) buffer has reached its 
empty condition alter flushing the lasi data going out to the 
ITU chip. Al this poini the card is ready to lie serviced and 
rearmed for another E>MA transfer. 

For an inbound DMA transfer, the EISA DMA request signal 
( EIDRQ) is asserted by the inbound EISA DMA state machine 
when the EISA DMA circuitry is configured and armed on 
the EISA HP-IB card by its driver and when either the FIFO 
buffer is partially filled with the last -data flag set, or when 



the FIF* ) buffer is full. The condition of (he FIFI > buffer be- 
ing full is necessary lo optimize the use and performance of 
EISA and to maximize use of the FIFO buffer. However, a 
peripheral on the HP-IB may not always send back enough 
data to the card lo fill the FIFO buffer, and the buffered data 
may sit here for an unexpectedly long period of time if it has 
to wail for the buffer to fill up completely. To get around the 
problem of having stale inbound data in the FIFO buffer, an 
external last-data flag is set by the ITU when it delects the 
HP-IB end-or-identify (EOI) signal. The HP-IB EOI signal is 
asserted by the peripheral lo signify lhal the last data byte 
was sent to the card during an I IP IB data transfer sequence. 
The flag status and the FIFI ) buffer status information are 
used by the inbound EISA DMA stale machine. In Ibis case, 
the stale machine will assert the EISA DMA request signal if 
the last-data flag is set and there is data in I he FIFO buffer. 
This ensures thai the last chunk of inbound data will be 
properly flushed from the partially filled FIFO buffer. 

The card will interrupt the system following the completion 
of the inbound DMA transfer when the EISA terminal-count 
signal is asserted by the system (indicating the last EISA 
DMA cycle), or when the last -data Hag is set and the FIFO 
buffer hits reached its empty condition after flushing the last 
data going into system memory. The former situation will 
occur when the DMA counter in the DMA controller 
matches the inbound DP-IB data count exactly. A more likely 
scenario is the latter situation, lhal is. (lie DMA transfer ends 
upon the setting of the lasl-dala flag. When the DMA counter 
is loaded by the driver with a value greater than (lie prede- 
termined amount of data lo be receiv ed from the HP-IB pe- 
ripheral, the termination of the inbound DMA transfer is 
controlled by the card and not the DMA controller. The card 
can "prematurely* end the transfer (with respect to the sys- 
tem) by deasserting the EISA DMA request signal and inter- 
rupting the system when the HP-IB EOI signal is delected 
during a data transfer. The Interrupt service routine will han- 
dle the residual value in I he DMA counter. At Ibis point the 
card is ready to be serviced and rearmed for another DMA 
transfer. 

The HP EISA PSI Card 

The HP EISA programmable serial interface (PSI) card pro- 
vides the means to support X.25 and SNA on Series 700 
workstations. The card is programmable in thai the network 
protocol code is downloaded from the host system into the 
card's memory for execution by the card's microprocessor. 
This makes it possible to use the same hardware platform 
for X.25 or SNA functionality. The EISA I>SI card is a 32-bit 
Typc-C EISA DMA module capable of.'W-Mbyte/s transfers 
on EISA using any one of seven DMA channels. Two hard- 
ware interfaces are supported on the single frontplane port: 
HS-2-'i2 and V,:!5. The proper frontplane signals are automati- 
cally selected depending on which interface cable is plugged 
into the frontplane connector. The user does not have lo set 
any switches or jumpers to configure the frontplane. 

In general, a card such as the EISA PSI would use a micro- 
processor to run the networking protocols, a local DMA 
controller to manage the data transfers on the card, and a 
serial controller to do the protocol conversions for the front- 
plane interface. In the past, this would have required three 
separate chips. The EISA PSI card uses the Motorola 
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MC68302 integrated multiprotocol processor, which inte- 
grates these three functional blocks and other support cir- 
cuitry into a single chip. The core of the MC68302 is a 
Motorola M68000 microprocessor. The MC6S302 provides 
three serial communications controllers, each with its own 
supporting DMA channels. One of these serial communica- 
tion controllers is used in lieu of a separate serial controller 
chip on the EISA PSI card. The MCI5S302 also provides an 
additional DMA controller (IDMA) whic h is indet>cndent of 
the DMA channels supporting the serial controllers. The 
EISA PSI card uses the IDMA instead of a separate DMA 
controller chip to manage the transfer of data between the 
card's SRAM and DRAM blocks. 

The EISA PSI card requires a large block of onboard mem- 
ory for the microprocessor's protocol firmware and the data 
to be processed and transferred across the frontplane. If this 
memory is also interfaced directly to the EISA bus. the host 
can transfer data via DMA directly to and from this memory. 

One of the requirements of the EISA DMA process is that 
upon receiving its DMA acknowledge signal. DAK*<x>. the 
DMA device must be able to provide data on an inbound 
transfer or receive it on an outbound transfer immediately. 
The DMA device is not allowed to delay the transfer by in- 
serting wait states. If the DMA acknowledge is received 
while the card's microprocessor is accessing memory, this 
requirement would be violated because of the time required 
for the microprocessor to release memory to I he EISA DMA 
process. 

One way to solve this problem would be to keep the micro- 
processor from accessing memory as soon as an EISA DMA 
transfer is requested by the card, and not releasing access to 
the microprocessor until the DMA transaction is complete. 
This was nol an acceptable solution for the EISA PSI card, 



since the latency between the request of DMA by the card 
asserting DRQ<x> and the commencement of DMA on receipt 
of the DMA acknowledge signal is variable because of the 
arbitration mechanism in EISA This time added to the EISA 
DMA transfer time would prevent the microprocessor from 
accessing memory for too long- 

If the MC68302 is blocked from accessing the memory hold- 
ing its firmware and data buffers for any significant length 
of time, the microprocessor cannot execute code and the 
serial frontplane will be starved for transmitted data or over- 
run with received data. 

Therefore, we chose to implement two separate memories 
on the EISA PSI card: a fast SRAM on the EISA bus to act as 
a data buffer for DMA transfers, and a large 1Mbyte DRAM 
to provide space for the downloaded protocol firmware and 
data buffers (see Fig. 12). This approach simplified the card 
architecture considerably. The SRAM is isolated from the 
microprocessor data bus by tristale transceivers. This allows 
EISA DMA transfers to SRAM to execute while the micro- 
processor has full access to the data buffers in the DRAM 
memory. The entire EISA DMA transaction can be completed 
to the SRAM without any interference with the microproces- 
sor. This approach also had other benefits. The microproces- 
sor and DRAM controller use a 16-MIIz clock, and with this 
design, synchronization with the EISA bus clock is not re- 
quired. Separate memories also helped reduce the materials 
cost of the board. Since the protocol code requires 1M bytes 
of memory, an implementation with technology fast enough 
to support EISA DMA from the same memory would have 
been much more expensive than the DRAM used. 

The basic process for PSI outbound transfers starts with the 
EISA DMA transferring data from the host system memory 
to the card's SRAM. Then the M( '(>K:t()2's IDMA transfers the 
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Board-Level Simulation of the Series 700 EISA Cards 



The complexity and clack speeds of designs are increasing such thai traditional 
"breadboard" debugging techniques are no longer a feasible approach to design 
verification It has become increasingly important to verify the design before 
fabrication This can lead to a reduction m the number of printed circuit board 
passes, shorter design cycles, increased product quality, and increased engineer 
productivity 

The designs of the Series 700 EISA cards were verified through board-level simu- 
lation. Aggressive design cycles and recent successes with simulation led to 
widespread use of board-level simulation on the EISA card proiects 

Objectives 

The collective objective of board-level simulation was to help ensure first-pass 
printed circuit board success so that we could deliver defect-free hardware to nur 
software partners, helping to meet the short time-to-market requirement 

The EISA cards were considered to be risky, complex, and difficult to debug — risky 
because of the various comer cases in timing and function that the Series 700 
EISA bus would not exercise This possibility exists because of the variance in 
vendor interpretation and implementation of the EISA specification This inter- 
pretation problem is in the area of asynchronous slave transactions and in bus 
master protocol Our cards not only had to work in the Series 700 workstations but 
with other third-party machines The difficulty in debugging was that the architec- 
ture of the designs could not be modified easily if during the debug process a 
fundamental design flaw was uncovered Therefore, it was important to prove the 
architectures of the cards through simulation 

Modeling Techniques 

Although simulation libraries can be quite extensive In their model offering, in 
most cases a number of components do not have model support. Models may nol 
be available for a variety of reasons. These can include new devices, proprietary 
devices Icustom ASICs), and low-volume devices A design engineer with the task 
of creating models needs to select appropriate modeling techniques 

Several different modeling techniques are available tD the designer These include 
gate-level, behavioral, and hardware models Gate-level models consist of primi- 
tive logic functions that are native to the simulator. These include functions such 
as AND, NOT, NAND, OR, NOR, XOR. and XNOR From these primitives land others), 
the designer can describe most hardware functionality Behavioral models are 
software representations of hardware that describe the functionality using some 
hardware description language (HDL) such as Venlog HDL. VHDL IVHSIC (Very 
High-Speed Integrated Circuit) HOI, IEEE standard 1076-1987). and GHDLIGenRad 
HDI ) Behavioral models can also be created using programming languages such 



cliitii from I ho SRAM lo Hie DRAM, and Hie MC(i8302's serial 
controller transmits the data from the DRAM to Hie front - 
plane link. This entire process actually involves several 
more detailed steps. First, the host must set up the system 
for EISA DMA by programming the DMA controller in the 
Intel 82357 on the EISA adapter. Then the EISA PSI driver 
software must provide the card with some control informa- 
tion by writing lo specific registers located in the card's 
DRAM using EISA slave accesses. The MC68302 will be in- 
terrupted when the host has provided this information. To 
prepare the card for the EISA DMA transfer, the micropro- 
cessor loads a starting address into the address counter for 
the SRAM. EISA DMA does not prov ide addresses for the 
DMA device, so the EISA PSI card must create its own ad- 
dresses for the SRAM to point to where the data should be 
transferred. The microprocessor then writes to a special 
control register that serves to isolate the SRAM from the 
rest of the card by disabling the transceivers between the 



as C or Pascal Hardware models are real ICs used directly in the simulation 
through the use of special hardware and software interfaces. 

Gate-level modeling is usually applied from the switch level up to the MSI 
(medium-scale integration) level The limited coverage of this method is mainly 
because of the potential of using a significant amount of memory and being the 
slowest to process and simulate. It has the advantage of being potentially more 
accurate than other methods. All of the HP EISA cards used gate-level modeling 
for most of the standard TTL and PAL components on the cards The gate-level 
models for the PALs were created using a custom filter that takes as input an 
ABELt list hie and outputs gate-level HDL 

Behavioral modeling can be applied from switch level all the way up to system 
level The wide coverage of this method makes it a popular choice for engineers 
The accuracy, speed, and memory requirements are a function of component 
complexity and how the code is written. Devices such as the Intel 82596CA LAN 
Controller and the HP-proprietary 1TL1 HP-IB controller chips were modeled at this 
level Only the critical bus interfaces were modeled on the 82S9BCA The 1TL1 
model not only modeled the local-host interface and the HP-IB interface, but also 
included two FIFOs which allowed more accurate modeling Behavioral modeling 
supports as much complexity as required. In some cases the engineers opted for 
more skeleton-type models in which timing accuracy and more functionality were 
required 

Hardware modeling is applied when there is no model available, the component is 
available in silicon, the level of functional accuracy is important, or the device is 
sufficiently complex to justify this approach over a behavioral technique This is 
usually considered the most accurate approach in terms of functionality, even real 
device bugs are visible in hardware modeling The disadvantage of this approach 
is poor timing accuracy because in some cases the clock cycle time may be limited 
and only typical times can be represented. We did not use this method. 

A final, and perhaps less popular method uses stimulus and assertion capability to 
model the interface of a particular component This method is only suited fot 
those devices that serve as bus interfaces for the board such as the backplane 
bus, the fromplane bus, and the frontplane/backplane interface chip The HP EISA 
cards all used vectors to model the bus transactions of EISA rather than a bus 
exerciser Isee below) In addition, the EISA SCSI card protect team elected to 
provide stimulus and assertion checks for the NCR 53C71 0 SCSI chip using vector 
modeling rather than a traditional behavioral model 

t ABEL is a sohware product liom DATA 1/0 thai is used to generate JEDEC (Joint Election 
Device Engineenng Council) files which are used to program PALs 



SRAM and the I 'RAM. This same control register also acti- 
vates the slate machine on the card that handles the out- 
bound EISA DMA transfer on the card. The outbound state 
machine asserts the EISA DRQ<x> signal (the specific DMA 
channel is selected during initialization ) and controls stroll- 
ing data from the EISA bus into the SRAM after the OAK*<x> 
signal is received, tt 

When the EISA DMA. transfer is complete, the outbound 
state machine interrupts the M('<58302 microprocessor. The 
microprocessor then sets up the transfer of the data from 
the SRAM to the DRAM using its I DMA controller. The 
MG68302 has a lfi-bit data bus, but the SRAM and DRAM are 
32 bits wide. Two pairs of isolation transceivers are used to 
select the proper bytes for data transfers involving the micro- 
processor. After the data has been transferred to the DRAM. 

1 1 The EISA bus is a little endian IMSB is bvie 31 and Itie 68000 bus is a big endian IMSB :s bvte 
01 The endians are switched on the EISA PSI catl bv the DSA backplane transceivers shown 
In Fig. 12 
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Stimulus 

Stimulus, also called vectors, consists of signal patterns or waveforms Wat are 
appliea to the inputs of a circuit Stimulus can be generated by a vector genera- 
tion tool isucn as Guide, which >s oat of the HP internal LogicArch'tect tools) or by 
a command-driven model (bus exerciser) 

A bus exerciser is basically a user-generated behavioral model Us purpose is to 
issue bus transactions and check for proper circuit responses It 15 possible to do 



some sort of coded instruction that when decoded instructs the model to initiate 
some particular bus transaction in the process of executing this transaction the 
model can also check for prope' circuit response The ability to provide response 
checking (also called assertion checks) is a solution to the situation in which the 
simulator does not have the native capability to perform these checks directly 
This method is useful when the bus exerciser can be leveraged to additional 
developments because of the significant time that this approach requires 

The vector sets for the DSA cards were quite extensive and in one case exceeded 
100.000 bus cycles. The reason for the great number of vectors is the numerous 
permutations of various corner cases in both timing and function Again, this is 
because of the loose EISA specification, especially m the area of asynchronous 
slave transfers 

Assertion Checks 

The combination of a circuit netlist. user models, model libraries, and stimulus 
allows the simulator to generate circuit behavior in the form of signal responses 
The circuit response can be verified in two ways, either the simulator checks the 
specified output signals every clock cycle through strobe statements, or a final 
response file is generated and the checking is performed postsimulation by an 
additional tool GenHad simulators have the ability to perform signal assertion 
checks cycle by cycle. 

In our case, the GenRad simulator checks the particular outputs through the use of 
strobe statements These strobe statements are generated by the vector genera- 
tion tool Guide The vector generation tool issues strobe statements in response 
to user requests for assert checks This is done via a high-level language that is 
valid within the Guide environment When the simulator detects a strobe violation 
lexpected logic value different from actual) an erior message is issued to the user 
A violation can mean that the applied stimulus is in error, the logic level assertion 
check is incorrect, or the circuit design is not correct 

Process Description 

Schematic capture was accomplished using HP DCS (design capture system) The 
resulting HI-103* netlist was generated using HP DVI (design verification interface). 
HI-L03 was provided with libraries from two sources a site-compiled standard TTL 



the microprocessor does I he processing necessary for what- 
ever network protocol is running on the card. Then Ihe dala 
is transferred by Ihe MO>K-'i()2's built-in serial controller to 
the rrontplane. 

The basic process for inbound transfers is the outbound 
transfer in reverse — the M('(>8M()2's serial controller trans- 
fers the received data to the DRAM, then the M< !68302's 
IDMA is used to transfer Ihe data from Ihe DRAM to the 
SRAM, and EISA DMA is used to transfer the data from the 
SRAM to the host system memory. 

T he inbound process begins when the seiial controller in the 
MC(i8302 transfers the incoming data into a predefined loca- 
tion in the DRAM using its assigned DMA channel built into 
Ihe M('(iS.'i(l2. The microprocessor then executes Ihe neces- 
sary protocol processing on the data. Meanwhile, the host 
sets up the DMA controller on the KISA adapter for the EISA 
DMA transaction. As with the outbound transfers, Ihe host 
writes setup information to the registers in the DRAM on the 
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fig. 1. Design and simulation piocess 

library and a local user-built library Vectors were generated from the logicArchitect 
tool Guide HI-L03 outputs result and capture files, which are used to interpret the 
results of the simulation The capture file contains circuit stimulus and response 
data that can be viewed graphically using DVI or textually using the GenRad DIS- 
PRO tool, which produces the results of a simulation in ASCII form As bugs are 
discovered and fixed, the process cycles back to the beginning (see Fig 1). 

Results 

In all cases the EISA cards were delivered to our software partners with only a 
single printed circuit board pass The effort of simulation revealed numerous 
design flaws before printed circuit boards were created The process is not per- 
fect In all cases, the cards had at least one serious bug that was not caught by 
simulation However, these bugs were all resolved without leoparduing the deliv- 
ery of a first-pass printed circuit board to our software partners on time — our 
ultimate goal 

HI-L03 is ii registered liadnm.uk 11I GenRad, Inr. 



KISA PSJ card and I hen interrupts the MC683G2 to signal 
thai Ihe information is available. The microprocessor trans- 
fers Ihe data from the DRAM to the SRAM using its IDMA 
controller. Il then loads the starting address into Ihe SRAM 
address counter and writes to the control register to isolate 
the SRAM and signal Ihe inbound state machine to request 
DMA. The inbound slate machine asserls the EISA DRQ<x> 
signal and controls ihe slrobing or the data out of the SRAM 
onto Ihe EISA bus after the EISA DAKVx> signal is received. 

Memory and I/O Slave Overview 

Another type of device thai can be placed on the EISA bus is 
a memory or I/< ) slave device. EISA supports 8-bit, Hi-bit, 
and :)2 bit data transfer cycles for slave devices. This includes 
ISA compatible liming for ISA memory and I/O slaves, EISA 
memory and I/O slaves can support .12-hii data transfers, but 
burst cycles and full .'!2-hii addressing are available 10 EISA 
memory slaves only. 
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The slave devices are accessed by Ihe host CPU or bus mas- 
ter. The standard EISA memory and I/O cycle type completes 
one transfer every two BCLK periods assuming no wait stales. 
Slower slave devices may lengthen a transaction by inserting 
wait states. 

Each EISA card must support some form of I/O slave access. 
This enables the system to read the EISA identification in- 
formation from the card during the EISA configuration pro- 
cess. Nonbursl memory or I/O transfers are not as efficient 
as burst DMA transfers for Ihe movement of data, so the 
slave interface is generally used for sharing control and sta- 
tus information between the system and the EISA card. 

For example, the EISA PSI card supports three types of 
slave interfaces. It provides an 8-bit EISA I/O slave interface 
for access to Ihe EISA information stored in the architected 
EISA identification and control registers. The card also pro- 
vides a 16-bit EISA I/O slave interface for access to its con- 
trol and status registers. Finally, the card has a 32-bit EISA 



memory slave interface to allow the system quick and direct 
access to onboard DRAM without having to go through the 
EISA DMA process. (The DMA process requires some over- 
head to set up, which is not very efficient for accessing just 
a few bytes at a time.) The DRAM is mapped into the system 
memory space so that it can be a shared resource bet ween 
the system and the card's onboard microprocessor. This 
allows efficient access to the stacks of information related 
to the control of the network protocols running on the card. 
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Software for the HP EISA SCSI Card 



Two software architectures, one offline and the other online, are used to 
provide EISA SCSI support for the HP 9000 Series 700 workstations. 

by Bill Thomas. Alan C. Berkema. Eric G. Tausheck, and Brian D. Mahaffy 



The SCSI (Small Computer System Interface) bus requires 
support from many offline and online software modules. 
Much of the software has a layered structure and runs dur- 
ing the normal run time of the HP I X* operating system. The 
SCSI interfaces for the HP 9000 Series 700 include the built-in 
5-Mbyte/s single-ended SCSI interface and an optional add-on 
HP 22525A EISA SCSI interface card with a 10-Mbyt.e/s dif- 
ferential SCSI bus.t This article will focus on the optional 
add-on HP EISA SCSI interface card. 

The EISA SCSI software falls into three categories: software 
that runs before Ihe system is completely booted (offline 
software), software that runs after the HP-UX or MPE sys- 
tem has started running (online software), and special test 
software that provides workloads and stress conditions not 
normally achieved by run-time system software. 

In a running system a layer of software drivers provides the 
interlace between the user's program and Ihe interface card. 
Each I/O request may involve different layers depending on 
the kind of request and type of device. Fig. 1 shows the ar- 
chitecture for the EISA SCSI software drivers. In this archi- 
tecture the HP-UX kernel, on behalf of a user process, starts 
an I/O operation by invoking a peripheral device driver 
through an open, read, write, or close procedure. The pe- 
ripheral device driver converts the request into one or more 
SCSI commands and passes them to the transport layer. The 
peripheral device driver and the transport layer are not de- 
pendent on the implementation details of the SCSI interface 
or the I/O bus hardware. The transport layer determines 
which SCSI interface the request is for and passes the com- 
mands lo Ihe appropriate inlerface driver. The interface 
driver is aware of ihe implementation of Ihe SCSI inlerface 
and operates accordingly. 

Offline software and firmware runs before the HP-UX system 
is functional. This software includes the processor depen- 
dent code (PDC), the I/O dependent code (10DC), the initial 
system loader, the HP-UX loader, the lomap program, and the 
SCSI product verification program. All of this soil ware is 
required so that the EISA SCSI inlerface can be used lo boot 
the system. Processor dependent code provides a standard 
uniform access lo certain basic opcratioM Of the syslem 
such as syslem reset and boot, system information (e.g., 
time of day ), and the ability lo load I/O dependent code. 
Each computer system (e.g., Model 710, 720, or 750) has its 
own version of processor dependent code stored in POM on 
Ihe CPU board. The I/O dependent code contains informa- 
tion about its associated hardware and procedures that are 
loaded and executed during boot up. These procedures 

I Differential SCSI uses differential transceivers for belter noise immunity, providing longer 
cables and higher transfer rates. 
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lesl the hardware, del eel deviees (e.g.. disks) connected lo 
it, and read and wrile dala to and from Ihese deviees. Eaeh 
I/O eard connected lo die EISA I/( ) bus dial might be a po- 
tential hoot device has a ROM containing l/< > de|i<'iident 
code. For built-in interfaces such as the built-in SCSI port, 
the I/O dependent code is located in the same liOM as the 
processor dependent code (see Fig. 2). 

The iomap program permits the user to examine and lest the 
hardware without having lo load the IlP-tJX operating sys- 
tem. The SCSI product verification program can also be run 
without the operating system. Because the operating system 
is not loaded for Ihese programs, testa and other operations 
can be performed (hal the Operating system would prevent 
from running. 

This article will discuss the implement at ion of some of Ihese 
software modules and the lest process for the interface 
driver. 

Offline Software Modules 

The processor dependent code and I/O dependent code 
mentioned above are called offline modules because they 
are only used once, and thai is during the boot process. 

Booting the System 

A system power-on or reset initiates the boot process. The 
boot process begins wilh the processor dependent code 
stored in ROM on the ( IT board first checking the proces- 
sor and memory and then beginning a search for other sys- 
tem hardware wilh particular interest in finding a device lo 
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boot from. The possible local ions of boot devices include 
the server nodes accessible through the built-in LAN inter- 
face or other devices connected to the built-in SCSI inter- 
face. Bool devices also include devices accessible through 
the EISA I/O bus such as a SCSI device connected to the 
EISA SCSI interface. For the configuration shown in Fig. 2. 
the boot process would proceed as follows: 

I. The resel procedure in the PDC ( processor dependent 
code ) is executed. 

2 The PDC does a self-test (on the processor) and then 
searches for oilier hardware and finds: memory, a built-in 
serial port, a LAN port, a SCSI port, and iui EISA interface. 

■i. The PDC loads and executes the self-test procedure for 
each item found in step 2. 

4. The PDC finds that the built-in SCSI card can delect more 
hardware. 

B. The PDC loads and executes the built-in SCSI's IODC (I/O 
dependent code). 

6. The built-in SCSI's IODC reports the presence of three 
disks. 

7. The PDC finds that the EISA interface can detect more 
hardware. 

8. The PDC loads and executes the EISA interface's IODC. 

9. The EISA interface's IODC procedure reports the presence 
Of three I/O cards with IODC. 

10. The PDC loads the IODC for each EISA card and 
executes each card's self-test procedure. 

II. The PI )( ' finds thai the EISA SCSI card can detect more 
hardware. 

12. The PDC loads and executes the EISA SCSI card's IODC 
search procedure. 

13. The search procedure reports the presence of one disk. 

14. The PDC loads and executes the built-in serial IODC to 
Inform the user thai there are four disks and asks the user 
which one to use. If the user selects the disk on the EISA 
SCSI card, the PDC loads the EISA SCSI card's IODC and 
executes the procedure to retrieve the initial system loader 
stored on the disk. 

15. The initial system loader takes over I he the process of 
booting the system by running the hpux program, which is 
also stored as a file on the disk. 

At the end of the boot process and just before a system 
prompt appears on the system console, the EISA configura- 
tion utility (described below) is run by the hpux program. 

To detect a piece of hardware, information is retrieved from 
a reserved set of addresses in system memory and if valid 
values are returned from Ihese addresses, hardware is pres- 
ent. When a piece of hardware is detect etl, its IODC is read 
lo determine what kind of hardware il is and what revision. 
The IODC procedures for the EISA SCSI card and the initial 
system loader are discussed in more detail later in Ibis ar- 
ticle. When an IODC procedure is loaded and executed, il is 
loaded into system memory. 
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EISA SCSI Card Configuration 

The EISA bootable interface for HP 9000 Series 7(KI work- 
stations had to overcome the problem of needing a config- 
ured interface subsystem before the subsystem could be 
used to boot the system, while the utility to configure the 
subsystem could not be run until the host system had 
booted — a classic system configuration problem. Unlike the 
predominant EISA bus implementations on MS-DOS- per- 
sonal computers that have an internal disk drive to boot 
from, the Series 700 w orkstations need to provide a basic 
configuration for booting from many different types of 
external devices. 

Part of the EISA standard, which is intended for usability, 
specifies that EISA cards have no switches or jumpers. In- 
dustry Standard Architecture or ISA cards (the predecessor 
of EISA ) commonly had jumpers and switches for setting 
the card's basic configuration for I/O transfers. Series 700 
EISA cards rely on utilities run at system power-on to read 
basic configuration Information from the EISA EEPROM on 
the system motherboard to configure the card (set flip-flop 
states) for I/O transfers. Getting the configuration information 
into the EISA EEPROM was the problem we had tO overcome 
in designing I he Series 700 EISA SCSI card's software and 
hardware architecture. 

In EISA MS-DOS machines, the system boots from the Inter- 
nal disk drive and runs the EISA configuration utility to con- 
figure the EISA EEPROM for each of the interfaces installed. 
The Configuration programming information for a given in- 
terface is distributed on a flexible disk shipped with the 
EISA interface card. In a typical Series 700 workstation, an 
internal flexible drive is not always available (one is avail- 
able as an option, but it is somewhat rare). Therefore, for 
the Series 700 workstations Ihe solution was to move the 
EISA configtiral ion program l<> the system's boot ROM. In 
addition, code for configuring (setting the bits) on the inter- 
face, whic h is normally distributed on ;i flexible disk for an 
MS-DOS machine, is incorporated into the i/o dependent 
code on the interface cards. 

On MS-IH IS systems. EISA configuration information is 
found in a CFG file on the flexible disk that comes with 
MS-DOS EISA cards. By using special execution options, the 
HP-I !.X EISA configuration program generates an image of 
the configuration information found in the CFGt file and 
stores it in the [OIK ' ROM when the ROM is programmed. 

The process of getting configuration information from the 
IODC ROM on an EISA card to the EISA EEPROM on the 
motherboard takes place during the boot process described 
above. When the PDl ' is examining each EISA card, it reads 
the EISA card's identification bytes. If the bytes do not 
match those found in the EISA EEPROM location for that 
slot (as is the case when the card is first installed), the 
PDC's configurator program reads the default ( CFG ) configu- 
ration information from the card's IODC ROM and places it 
into a "special location" in the EISA EEPROM. If the identifi- 
cation bytes from the interface c ard match those found in 
the EISA EEPROM for that slot, the PDC's configurator 
program initializes the EISA card (see Fig. .la). 

When the PDC loads and launches the IODC for a particular 
EISA card, the IODC will examine (he stale of the Card to 

t For Wis HP-UX operating system Ihe CFG tile comes as pan ot the system software 



determine if it had been preinitialized by the PDC's configu- 
rator program. If the card has been initialized, the state of 
the card is not changed. If the card is found to be uninitial- 
ized, the card is configured to the default CFG information in 
the IODC ROM (see Fig 3b). For the Series 700 EISA SCSI 
card, the default configuration includes setting parameters 
Tor the SCSI address and parity checking with values com- 
monly used by most systems. 

When the initial system loader takes over the HP-CX boot 
process, one of its tasks is to run the eisa_config (EISA config- 
uration) utility. When eisa_config runs it interrogates the EISA 
EEPROM for any IODC (default ) configuration information 
that might exist in the special area of the EISA EEPROM. If 
it finds the default information. eisa_config will enter an auto- 
malic configuration mode, validate the default values and 
move them to the appropriate place in the EISA EEPROM 
that matches the slot the EISA Card is installed into (see Fig. 
3c). The next time the system is booted, the appropriate 
information for configuration will be available. The system 
administrator can run Ihe eisa_config utility manually and 
modify Ihe configuration of the interface. In the same way 
as for the default configuration. Ihe eisa_config utility will 
save the configuration initialization information in Ihe ap- 
propriate location in Ihe EISA EEPROM so it will be avail- 
able at the next bool time. 

HP EISA SCSI I/O Dependent Code 

The EISA SCSI I/O dependent code (IODC) is designed ac- 
cording to ihe PA-RISC outline for bootable interfaces. The 
IODC ROM contains software modules that can be loaded 
into host memory and executed by the hosl processor (see 
Fig. 4). Two major entry point software functions are de- 
fined for the SCSI IODC: ENTRYJNIT and ENTRY JO. The 
ENTRYJNIT function call is for inilializalion or both the EISA 
SCSI card and devices on the SCSI bus. The ENTRY .10 func- 
tion call is for I/O clala transfer between the workstation and 
the SCSI devices on the bus. Each of these function entry 
points has several subfunclions. The ENTRYJNIT function 
provides testing Of the SCSI card, searching for devices on 
the bus, device initialization, device testing, and testing of 
data transfer integrity. The ENTRY. 10 function has functions 

for read and write for both character and blocked data type 
devices. 

The first subfunction for ENTRYJNIT is Ihe INITIALIZE fund ion. 
During the inilializalion process, care is laken to preserve 
t lit- card's Configuration parameters for the SCSI address, 
parity checking, and so on if the card lias already been con- 
figured by Ihe PDC configtiral or during bool. Aflerlhe card 
configuration has been noled the INITIALIZE function resets 
the card to a known stale and performs low-level self-testing 
of the hardware. The self-test includes a full register check 
of the NCR 53C710 SCSI controller chip. DMA and FIFO 
data transfer tests, 5:!C710 script execution tests, and offline 
SCSI bus data and parity lesls. Upon successful completion 
of the Self-test routines, either the saved card configuration 
or Ihe default configuration is used, as appropriate, to set 
the interface card to an initial configured slate. 

The next function of ENTRY INIT is the linked pair of calls 
SEARCH .FIRST and SEARCH NEXT. These I wo calls are actually 
Ihe same subroutines called with slightly different initial 
parameters. The purpose ot these routines Is to search the 
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SCSI bus Tor any devices of a type the IODC knows about. 
The IODC knows about both character (tapes) and block 
(disk) lype devices, bin currently only disks are offered in a 
differential interface for purposes of booting the system. 
The SEARCH_FIRST routine is called first with an empty device 
identifier record passed as a parameter. The routine searches 
from the highest available SCSI address downward until it 
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either finds a device or runs out of addresses to try. If a de- 
vice responds to the search, it is interrogated to find out if it 
is a device the IODC knows how to handle. If Ihe IODC 
knows Ihe device, the device identifier record will be filled 
with Ihe device's data and address location. Subsequent 
searching is done by calling SEARCH_NEXT with the address 
information maintained in the device identifier record. 

the remaining subfunetion for ENTRYJNIT is the INIT_DEVICE 
(unction. The device needs to be found on Ihe bus firsl by 
the SEARCHJIRST and SEARCH_NEXT functions before the 
INIT_DEVICE function is called. Once it is found, the targeted 
device will be reset to a known slate then a series of confi- 
dence building steps will be laken to ensure proper commu- 
nication is possible with Ihe device. First, an internal self- 
tesi function lhal all SCSI devices have buill into them is 
run. When the device responds that it has passed its self-test. 
Ihe INIT_ DEVICE code will then use the device's internal buffer 
RAM to write a small amount of test data to the drive. The 
data just written will then be read back from the drive's In- 
ternal buffer and verified for correctness with what was 
originally written to the drive. After all theses tests have 
been successfully completed, control will be returned to the 
calling routine. 
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ENTRYJO has less functionality than the ENTRYJNIT function, 
bui is the function that docs the "real work." Four subfunc- 
tions are associated with this function, two for data writes 
and two for data reads. The read and write subfunctions are 
very similar in design and functionality. One subfunction 
pair ( read and write) is for character-based SCSI devices and 
the other pair is designed for block transfer devices. Boot 
support for these devices is present in the IODC if they arc 
ever produced in a differential SCSI version. 

Certain types of request validation and parameter checking 
are common to the four subfunctions in ENTRYJO. First a 
check is made to verify that the device being read from or 
written to has a block size that is an even factor of 2048 
bytes. The transfer is next checked to ensure that il is not 
larger than the maximum size the IODC can handle (because 
of memory mapping restrictions), and thai the transfer size 
is a multiple of the block size of the SCSI device. The last 
check of parameters is only for sequential requests. If the 
data address is zero the tape is rewound first before the 
write or read is performed. After the parameters have been 
v alidated (he request is translated to the appropriate SCSI 
commands and sent oul lo the SCSI bus. 

Initial System Loader 

The initial system loader is responsible for gelling the hpux 
program from the boot device and running it. The inilial sys- 
tem loader can take instructions from the user or use com- 
mands in the AUTO Tile on the boot device discovered by the 
IODC's SEARCH functions. If the instructions come from the 
user, the loader will prompt the user for what to do. The 
user can command the loader to inn hpux to boot the HP-OX 
system with parameters that are the same as or different 
from those in the AUTO file. Also, the user can command the 
inilial system loader to run (he lomap utility lo map and lesl 
the system, or run the SCSI Product Verification and Defect 
Analysis (scsipvda) utility lo rigorously lesl and diagnose the 
S( si Interface. 

The lomap program can search for all components in the sys- 
lem including processors, memory, CPU bus converters, 
interface cards, disks, and so on. The iomap program can also 
invoke the self-test program for components that have self- 
lest in their IODC ROM. 

Running self-test programs in the inilial system loader (or 
boot ) environment has some advantages over running them 
in (he lll'-l'X system environment. Diagnostics that run 
under Ihe HP-UX operating system have many other advan- 
tages, but if the system will not boot, these run-lime diag- 
nostics cannot be used. The advantages of Ihe boot environ- 
ment include unrestricted access to system resources such 
as the SCSI interface configuration registers and no depen- 
dency on many system functions such as a functional file 
system. Also, diagnostics running in Ihe boot environment 
do not have to contend with concurrent activity on multiple 
devices and interfaces. The diagnostic has complete control 
over what activity oc c urs and when it occurs. To enhance 
user friendliness, special messages for the user have been 
included in Ihe iomap program specifically to aid testing of 
the SCSI interface. These messages are used when the SCSI 
|i )| ii encounters a failure. These messages inform Ihe user 
about what action to lake, such as lo check (he cabling or 
Ihe power-on State of a device. 



The verification and diagnostic utility scsipvda also mns un- 
der the initial system loader. Like the iomap program, (his 
program runs the IODC of the SCSI interface. The scsipvda 
program also runs additional tests that cannot run under the 
HP-UX operating system, such as testing the card with dif- 
ferent configurations of the I/O memory" mapping hardware. 
Once the HP-UX system has started, the diagnostics for 
SCSI devices, disks, and magnetic tapes provide confirma- 
tion of the SCSI interface functionality, although not with 
the completeness possible with scsipvda. 

HP-UX Run-Time SCSI I/O Modules 

The run-time SCSI modules run in the HP-UX kernel and 
provide the interface between user-level programs and SCSI 
devices. 

Peripheral Device Drivers 

Fig. 1 shows Ihe logical relationship between the run-time 
modules. Each peripheral device driver is compiled sepa- 
rately and is built when Ihe kernel is created. Each driver 
has knowledge of how to manage a particular peripheral or 
set of peripherals and each has a standard driver interface 
that the operating system uses for virtual memory and file- 
system management and for providing user applications 
with an interface to device capabilities. 

A peripheral device driver provides open, close, read, write 
and control (ioctlll) functions to the kernel. The drivers trans- 
late these function calls and their parameters into the 
proper state management of the peripheral through the use 
of command sequences appropriate to the state of the device 
being managed and the HP-UX operating system functions 
requested by a particular device driver. 

The SCSI standard specifies the command sets, their func- 
tions, and the possible replies for general classes of periph- 
erals (e.g.. a random-access class and a sequential-access 
Class). This standardization has made il possible to write 
one peripheral device driver for a given class to handle a 
wide variety of peripherals from multiple vendors. For ex- 
ample. Ihe same peripheral device driver for disks can be 
used for handling flexible, magnetooptical, and hard 
magnetic disk drives. 

For the SCSI driver subsystem, the responsibility of a periph- 
eral device driver is limited to those aspects of the protocol 
that concern the device Ihe driver is controlling. Details 
about the physical link to the device and the protocols nec- 
essary for I/O processes to communicate between the host 
Interface and the devices is a common service needed by all 
device drivel's and is provided by the interface drivers. 

Interface Drivers 

Software interface drivers manage the SCSI bus aspects of 
I/O processes between all (he peripheral drivers and a given 
SCSI interface An interface driver takes I/O requests com- 
ing from a peripheral device driver via Ihe transport layer 
and presents the requests lo Ihe SCSI bus. When an I/O pro- 
cess is done, Ihe interface driver makes a function call back 
lo ihe appropriate peripheral device driver. 

Since the SCSI bus interface can connect to multiple S< SI 
dev ices, the interface driver also provides a multiplexing 
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service for access and Control i if I he SCSI bus on behalf of 
all of the peripheral device drivers. 

The SCSI standard defines another (wo levels of optional 
multiplexing with a SCSI device: LUNs (logical unil num- 
bers) and tagged queuing on each LUN (see "Update on the 
SCSI Standard" on page 103). Peripheral device drivers that 
use these features need support from the SCSI protocol han- 
dled by the interface drivers to support these levels of 
multiplexing. 

Interface Driver Implementation for EISA SCSI 

The SCSI standard defines the LUN and tagged queuing fea- 
tures hut not the implementation or application of the fea- 
tures. The interface driver provided vviih our first EISA SCSI 
release is designed to support only one LUN and floes nol 
use SCSI tagged queuing because none of the peripherals 
supported in the first release use this option or have more 
than one LUN. 

Since the newer disk array products are best used with multi- 
ple LUNs and lagged queuing, a special project was commis- 
sioned to design and implement an interface driver to sup- 
port these SCSI features. This required some rethinking about 
the architecture of the built-in ( single-LL'N ) SCSI interface 
driver and consideration of methods to minimize interface 
overhead to meet the increased throughput potential that 
some of the newer SCSI peripheral devices offer the system 
on a 10-Mbyte/s differential SCSI bus. Fig. 5 shows the con- 
figuration of a system with single and multiple LUN devices. 

We learned from an earlier project that the protocol for man 
aging multiple LUNs and tagged queuing is largely software 
queue management, and that a clear line of functionality can 
be drawn between the part of the interface driver that con- 
trols the hardware-specific aspect of the SCSI bus and pro- 
tocol and the purely software aspect of queue management 
for I/O processes. 

We went one step farther and defined a simple way to 
reuse the software queueing portion of the interface driver 

To Built-in I/O ASIC 
(see Fig.1) 



to provide for the possibility of future SCSI bus interface 
designs, or perhaps non-SCSI bus links to SCSI bus peripher- 
als. This division of functionality for the new interface driver 
also allowed a division of labor between die project team that 
diil the software for the hardware dependent portion of the 
interface driver and the project team that did all the other 
system software necessary to support disk arrays. The team 
that worked on the hardware dependent software focused 
on the task of implementing and proving a full-featured, 
high-performance, low-latency SCSI-2 standards-compliant 
solution using the EISA SCSI bus interface card. 

The design team tailored the EISA SCSI hardware to make it 
look enough like the built-in interface so that the system soft- 
ware could be easily modified to support the new SCSI bus. 

The HP 25525A EISA SCSI interface design includes a SCSI 
interface chip (NCR 53C710) with backward compatibility 
with the chip used for built-in SCSI (NCR 53C700). These 
interface chips are special-purpose processors that execute 
an instruction set called SCSI SCRIPTS ( from NCR) and use 
DMA to transfer data between host memory and the SCSI 
bus. The host CPU builds the instruct ion stream in system 
memory that the SCSI processor eventually executes (one 
SCRIPTS instruction at a time) to make decisions based on 
SCSI bus activity and to do the appropriate DMA transfers. 
The instruction stream provides flexible test and control of 
the SCSI bus while reducing the amount of host interaction 
and host-induced latency for SCSI bus protocol processing. 

The new interface driver provides the func tionality required 
to support disk arrays on the 10-Mbyte/s differential SCSI 
bus. However, the driver does not support the built-in SCSI 
interface because it is optimized lor the HP25525A hardware. 

We also designed the interface to provide optimized proto- 
col support for the SCSI bus lo minimize SCSI bus overhead. 
This optimization potential results from some additional 
circuitry anil the flexibility of the 53C710 chip used on the 
HP EISA SCSI card. 



(continued on oage 1041 
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Fig. 5. The configuration of a system with single and multiple LUN SCSI devices 
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Update on the SCSI Standard 



The SCSI (Small Compute? System Interface! bus is an intelligent gene?ai-puTpose 
I/O bus defined fa ANSI committee standard X3 13' SCSI-2 is an enhancement to 
the original SCSI standard It is designed fo? highe? performance and greater pe- 
ripheral connectivity Some of the SCSI-2 features are dese-ined betow 

I/O Processes and the I T L and I T I Q Nexus 

Trie HP EISA SCSI card is an 8-bit SCSI implementation The 10-Mbjie/s data 
rates are achieved using the SCSI-2 fast timing specifications and a targei SCSI 
device that also implements fast SCSI-2 timing 

The SCSI bus used m our design allows one host to control up to seven other SCSI 
device interfaces on each SCSI bus It is a baif-duple» interface bus. which means 
that information can travel either way between two devices but not at the same 
time. 

Each SCSI device has a unique SCSI identifier SCSI identifiers are used to resolve 
contention for the bus through a priority arbitration protocol Each data line is 
used to represent a different SCSI identifier during arbitration so that all contend- 
ing SCSI devices can oe determined at the same time. After arbitration, the data 
lines are used by the arbitration winner to select the SCSI identifier of the SCSI 
device with which it Is reconnecting or establishing an initial connection. 

A SCSI initiator is a SCSI device that initiates SCSI I/O processes through initial 
connections The initiator is usually represented by the host system and for this 
discussion is controlled by the interface driver for the HP 25525A EISA SCSI card 
A SCSI target responds to initial connections from the initiator and uses the ap- 
propriate SCSI protocol steps for each I/O process including reconnecting. Several 
real or logical peripheral devices may be behind a SCSI large! interface 

A SCSI I/O process is the state of a single SCSI command execution starting from 
the lime thai the target receives a SCSI command descriptor block from the initia- 
tor during initial connection until when the target communicates its completion 
back to the initiator 

A SCSI nexus, which is a relationship that begins with the establishment of an 
initial connection and ends wilh the completion of an I/O process, identifies an I/O 

process between the initiator and target A SCSI I T L (iiniiator_targot_LUN) nexus 

is composed of the initiator's SCSI identifier, the target's SCSI identifier, and one 
of eight possible addresses called logical units or LUNs within the target These 
logical units may represent distinct physical or logical peripheral devices SCSI 
protocol allows the initiator 10 send one I/O process at a lime per l_T_l nexus. 

The I_T_l_Q |initiator_target_LUN_queue) nexus is an optional layer of I/O pro- 
cess identification and protocol that allows concurrent I/O processes to be pend- 
ing ai the logical unit ihrough a mechanism called SCSI tagged queueing ' Tagged 
queuing is a feature of SCSI-2 that allows a peripheral to manage I/O processes 
more efficiently 

All SCSI-2 devices support l_T_L nexus connections Through these connections 

device drivers can use I/O processes to determine for each possible I T L nexus of 

interest which of the eight possible LUNs at a given SCSI identifier exist and which 
of these, if any, support an l_T_L_Q nexus connection Typically all SCSI devices 
support LUN 0 Most of the existing or older devices only support LUN 0 and do 
not support l_T_L_Q nexus connections Newer devices, particularly those that 
integrate multiple devices at one SCSI identifier, are beginning to appear that have 
multiple LUNs and require l_T_L_Q nexus connections for optimal performance 

The SCSI initiator's responsibilities include starting I/O processes through an initial 
connection of the appropriate nexus and checking for appropriate SCSI protocol 
steps for the lifetime of each I/O process The SCSI target is responsible for re- 
ceiving the initial connection from the I/O process and taking the appropriate SCSI 
protocol steps for the lifetime of each I/O process 

During initial connection the peripheral device receives a SCSI command descrip- 
tor block thai identifies the particular I/O process function to be processed The 
command descriptor block implicitly describes the appropriate SCSI protocol steps 
the initiator will expect the target to follow and what effect the command and 
data, if any. have on the peripheral device identified within the nexus. 



Typically. I/O processes direct a peripheral to locate and move some number of 
device-specif ic blocks of data between the device Ithroogh us target interface to 
the SCSI bus) and host memory (through the mmator interface to the SCSI bus) 
fig ! shows the typical SCSI bus activity for such an I/O process 

A typical I/O process has three protocol steps— command, data, and status— which 
use the SCSI phases COMMAND DATA IM and DATA OUT 3:i3 STATUS, respectively.'' 

The target is usually given permission IDISCPRVI to release the SCSI bus at any 
appropriate time during I/O processing A correctly implemented and configured 
SCSI target on a SCSI bus with more than one device on the same bus will release 
the bus when it anticipates long delays between data transfers These long delays 
are typically the result of mechanical movements and occur between the COMMAND 
and DATA phases, during the data phase, or between the DATA and STATUS 
phases The MESSAGE phase is used to manage SCSI bus multiplexing of different 
nexuses 

After a cable delay of a few microseconds, the DATA phases operate at full SCSI 
rates for the duration of the phase Fig I shows about 30 SCSI bus primitives of 
overhead needed to transfer the application data for one I/O process These pnmi 
tives transfer at a rate limited by the round trip delay between the initiator and 
target on the SCSI bus. typically 1 Mbyte/s. 

The acknowledgment of each primitive may require processing time and shows up 
as initiator or targei SCSI bus overheads These overheads range from one to 
several hundred microseconds up to several milliseconds. 

Multiplexing the SCSI Bus between Nexuses 

A device that disconnects from the SCSI bus during long delays in I/O processing 
enables other SCSI devices to use the bus. When the bus is relinquished by a given 
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Fig. 1. Typical protocol steps lor one I/O process on an IJJUQ nexus 
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Multiple targets on a SCSI bus offer a higher aggregate throughput performance 
when they use the SCSI bus efficiently and only when necessary during I/O process- 
ing. Multiple LUNs associated with a target offer the possibility of more concurrent 
I/O processes, and even though contention for the SCSI bus may increase, aggregate 
throughput can increase until the SCSI bus is saturated with activity 

SCSI-2 tagged queuing provides even higher SCSI bus throughput by allowing 
initial connections to be pipelined to the device controllers so that the devices are 
never left idle waiting for the next command from the initiator If the peripheral 



device driver chooses to allow the device controller to reorder the queue-tagged 
commands within a LUN then the device can further improve utilization if it can 
reorder I/O process continuation 
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Performance Advantages 

The major performance difference between the EISA SCSI 
card and the built-in SCSI interface is that the built-in SCSI 
runs at the standard 5 Mbytes/s whereas the EISA SCSI card 
implements fast SCSI-2 timing with a 10-Mbyte/s potential 
(during bulk data transfer). t 

In comparing performance between a ij-Mbyte/s SCSI bus 
and a 10-Mbyte/s high-performance SCSI bus, one would 
expect a uniform boost in throughput. However, simply 
doubling the data rate capability of the SCSI bus is not suffi- 
cient. The fixed overhead of initial connection and recon- 
nection and the hundreds of microseconds involved in target 
and initiatortt overhead typically have a serious impact on 
performance. Fig. <> shows the effects of different SCSI over- 
head times for maximum sustained bulk data throughput of 
different lengths. 

Although a higher transfer rale may also have the advantage 
of a higher I/O process rate through the system, the increased 
performance levels require a higher rate of t he use of limited 
system resources like I/O bus cycles and CPU execution 
bandwidth. These factors can also limit improvements 
implied by a higher transfer rate. 

Meeting the high-performance expectations of a 10-Mbyte/s 
SCSI bus required focused attention on the overhead 
contributed hy the HP 25525A and on the system resources 
required per I/O process. 

Reducing Overhead 

Analysis of the graph in Fig. (5 shows that the benefits of a 
10-Mbyte/s SCSI bus are not. very significant until overheads 
are reduced from the millisecond range to the hundreds of 
microseconds range, particularly for the bulk data lengths of 
4096 and 8192 bytes. 

An analysis of the interface driver's execution path revealed 
that the following actions could be optimized in the new 
interface driver to reduce overhead: 

• Consume a queue of rcady-to-go initial connections by pre- 
senting them to the SCSI bus, minimizing the time thai the 
SCSI bus is idle when the queue is not empty 

• Service disconnections and their associated reconnect ions 
by managing each I/O process state on behalf of the targets 
as they progress through each of their I/O processes with 
minimal delay on the SCSI bus 

• Transfer bulk data by sustaining the highest transfer rate 
that the target is capable of 

t Bulk data is data transferred during the DATA IN or DATA OUT SCSI bus phases 

TI The initiator is the host system that starts an I/O process on the SCSI bus and the target is 
the SCSI device receiving I/O requests 
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anil block sizes for (a) 5-Mbyte/s transfer ratp and (b) 10-Mbyte/s 
transfer rate. 

• Produce I/O process completion messages to the host and 
its peripheral device drivers, minimizing the time from the 
target's reporting status until the target frees the bus. 

To reduce overhead and minimize the impact on system re- 
sources during the operation of the interface driver, we fo- 
cused on minimizing interrupts and maximizing transfer 
rates. In addition, we had some features added to the NCR 
53C710 chip to help us minimize interrupts (see "Adapting the 
NCR 53C710 to Minimize Interrupt Impact on Performance." 
on the next page). 
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Interrupt Minimization 

The most important contribution that the new driver makes 
toward reducing overhead is the minimization of CPU inter- 
rupts per I/O process and Lhe reduction of the performance 
cost of the remaining interrupts to both the CPU and the 
SCSI bus. 

In our design, the typical paths that a target takes during an 
I/O process result in one interrupt to the CPU al the end of 
the I/O process. Perhaps more significantly, for most of the 
interrupts that do occur in the performance path, the syn- 
chronization typically required between a chip and its con- 
trolling CPU during a given instance of an interrupt service 
routine is not required. The CPU and the chip continue on 
their separate paths while one or the other is servicing an 
interrupt, or has a pending interrupt. 

This independence is accomplished through the use of 
memory-based messages facilitated by flags and interrupts. 
The flags are actually parts of SCSI SCRIPTS instructions. 
This formal allows the chip (being much less flexible than 
the CPU) to participate in this interprocessor communica- 
tion. Depending on lhe particular flag, it may be a test condi- 
tion for a conditional branch instniction or il may be a des- 
tination address for a branch instruction. The CPU can set 
these flags one way, and with an instruction in the NCR 
53C710 chip that allows memory-to-meniory movement, the 
chip can set the flags the other way. 

The flags can be thought of as pan of the messages. These 
messages change ownership between the CPU and the chip. 
Interrupts are used to notify the CPI I and chip when a Hag 
changes and its message is ready for processing. 

The major message types in the design are for starting a new 
I/O process and notification of completion of an I/O process. 

Start of an I/O Process. A message from the CPU to the NCR 

53C710 chip to start a new I/O process is initially flagged as 
owned by the CPU. The CPU fills in the message with SCSI 
SCRIPTS and SCSI protocol data necessary to start the new 
I/O process. Then the CPU sets a flag to give ownership of 
the message to the chip. This handoff is accomplished using 
the CPU-to-chip interrupt described above. When the chip 
eventually completes the initial connection phases of the 
new I/O process, it returns ownership of the message to the 
CPU by resetting the associated flag. 

To minimize CPU interrupts, the chip does not need to inter- 
rupt the CPI as pail of handing the message buffer back to 
the CPU. The exception is when the CPU wants to start an- 
other I/O process while the chip owns the associated re- 
source message buffer. In this case, the CPU will set another 
flag to be notified via an interrupt by the chip once the chip 
finishes with the message buffer. 

As (he frequency of this condition increases, the number 
of interrupts per I/O process approaches two. We could 
have designed out these "extra" Interrupts by providing mul- 
tiple versions of this message buffer. However, we found the 
Frequency too low to justify the cost in design complexity. 

I/O Process Completion Interrupt. Initially the flag for the mes 
sage buffer associated with I/O process completions indi- 
cates chip ownership. When the chip encounters an I/O pro- 
cess completion, it will put enough information in the 



Adapting the NCR 53C710 to Minimize 
Interrupt Impact on Performance 

Whenever the NCR 5X710 chip interrupts toy asserting a chip interrupt line) it 
must first stop executmg SCSI SCRIPTS instructions It resumes executing instruc- 
tions only after the CPU writes to The appropriate chip register This is the kind of 
synchroni2ation interrupt that we wanted to avoid whenever possible so we addec 



some circuitry between the chip and the 


card's EISA interrupt circuit to allow the 


NCR 53C710 to assen a generai-purposi 


= output pin under SCSI SCfllPTS control 



which results m interrupting the CPU In this way the chip can continue executing 
after interrupting the CPU 

Another problem to solve was how to get the CPU to interrupt the instruction 
stream of the 53C710 chip without shutting the chip down through a cumbersome 
abort procedure We worked with NCR to modify the way some of the 53C710 
instructions worked so that for the instructions that wait for new SCSI bus activity 
to stan (the idle state in our design), a bit was added in a register in the chip that 
the CPU can write to during SCSI SCRIPTS execution When this bit is set either 
before or during an idle state, the chip takes an alternate branch from the idle 
state This gave us a CPU-generated interrupt to the chip. 

These two features gave us the ability to run the CPU and the NCR 53C710 in 
parallel almost all of the time 



message to indicate which nexust completed and the com- 
pletion status. Because of the chip's ability to address itself 
as the source of a memory-to-memory move instruction, 
some of the status information is posted to the message 
buffer by the chip. 

Once this information is written to memory, the message- 
buffer flag is changed to indicate CPU ownership of the 
message. Since the CPI' is anxiously awaiting the comple- 
tion of I/O processes, the chip interrupts il to notify it of the 
newly created message. Once the CPU has read the message, 
il resets (he message-buffer flag, giving back ownership of 
the message lo the chip. 

In the rare case in which the CPU does not process the mes- 
sage by the lime the chip has encountered another I/O pro- 
cess completion, the chip must interrupt and thus halt prog- 
ress because it only has one message buffer for writing 
completions lo and therefore it doesn't have the ability to 
remember completion information and continue servicing 
S( SI bus state changes at the same lime. 

The process completion interrupt will direct the CPU to pro- 
cess both the pending I/O process completion message and 
the pending I/O process completion still in lhe chip. In this 
case there is only one interrupt for t wo I/O completions, but 
the SCSI bus progress is stalled by the rate at which the 
CPU can acknowledge the message and pending interrupt 
and then resume Chip independence. 

A typical target SCSI protocol through the performance path 
is depicted in Fig. 1 on page 10:1. ( ilhcr performance paths 
follow the same sequencing but the target may choose not 
to disconnect between the major SCSI I/O process phases 
of COMMAND, DATA IN or DATA OUT. and STATUS. 

Peripherals in lhe HP-UX operating system environment do 
not usually disconnect in either the DATA IN or DATA OUT phase 

t A SCSI nexus is a lelationship llial begins with lhe establishment ol an initial connection and 
ends with lhe completion of an l/t) piocess See "Update on the SCSI Standaid" on page 1UJ 
lor more about SCSI nexuses 
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before all of the I/O process' data has been transferred. This 
is fortunate because, unless the disconnect .junctures can be 
predicted ahead of time, the NCR chip interrupts when this 
occurs. 

It was still a challenge for us to get the NCR 53C710 to be 
able to process each of the typical target choices through 
the performance path without GPU intervention once the I/O 
process is started. However, it was not difficult to imple- 
ment the case in which the target does not disconnect from 
the SCSI bus. For the cases in which the target does discon- 
nect, many intervening I/O processes may be started or re- 
sumed before the disconnecting process continues. There- 
fore, the slate at which the I/O process disconnects must be 
remembered. 

The I/O process state is remembered by storing it in each I/O 
process' memory in the form of SCSI SCRIPTS instructions. 
Initially the chip sets this state as pan of the information 
provided for starting the I/O process. 

Once the I/O process is stalled the chip can access the I/O 
process state by using what amounts to a computed GOTO 
instruction in the chip. The actual procedure used is to con- 
vert (through SCSI SCRIPTS execution) the SCSI nexus into 
the address or the SCSI SCRIPTS corresponding to the I/O 
process next-state actions. When the target reselects a 
nexus or continues on the same nexus, the associated SCSI 
SCRIPTS for the next state of the I/O process are executed 
and modified by the chip to reflect the new next stale of the 
I/O process. 

This feature of the design minimizes the lime required to 
react to reconnect ions, and decouples the response time 
from CPU interrupt service limes. CPU interrupt service 
times are often just as fast or faster in a lightly loaded sys- 
tem, but as the CPU workload and interrupt rate from other 
sources increase, the service times increase. However with 
our design the service time is only dependent on SCSI 
SCRIPTS memory access times and doesn't contribute to 
increased CPU workload. 

Maximizing Transfer Rate 

In our design, the first step in transferring data as fast as the 
target is capable of handling it is for the EISA data transfer 
to be able to keep up with a l()-Mbyte/s maximum SCSI 
transfer rate. The card doesn't buffer EISA data transfers 
beyond the 64 bytes provided in the chip so it is important 
for the card to be able to maintain the 10-Mbyte/s rate in real 
time. This problem was solved in hardware (see the article 
on page 83). 

The I/O map hardware and associated io. services software 
algorithms are used to map from contiguous virtual memory 
descriptions of data transfers by user programs, the kernel, 
and the file system into virtual, contiguous EISA address 
space. This is done so that the EISA hardware and software 
aren'l burdened with knowledge about PA-RISC page bound- 
aries and their discontinuities in real physical addresses. 
Although the NCR 53C710 is capable of dealing with non- 
contiguous addresses by using a separate SCSI SCRIPTS for 
each physical address range, the cost in performance is such 
that between SCSI SCRIPTS fetches the SCSI bus is idle and 
maximum data rates can't be achieved. In the case of our 
ll)-Mbyte/s EISA SCSI interface, the performance cost 



would have typically been only 1% without using contiguous 
EISA memory. However, since the io_services functions used 
for development of the interface drivers performed this opti- 
mization, we are able to sustain maximum SCSI burst rates 
for the duration of bulk data transfer. 

Testing the SCSI Interface Driver 

Test requirements were recognized as an important aspect 
of the interface driver development at the very beginning of 
the project and the software for testing provided special 
functions and workloads that the regular system software 
did not normally provide. Development of the test plan and 
the test software occurred in parallel with the development 
of the interface driver. 

The test plan goals were taken directly from the Roseville 
Networks Division software life cycle, which include: 

• Identifying test cases to verily detailed implementation 

• Developing all unit module and integration lest code 

• Verifying accurale functionality with fully implemented 
dependencies and hardware. 

Software developed to achieve the first two goals included a 
user-level test program, a test peripheral device driver, and a 
SCSI target emulator program. The purpose of the test soft- 
ware was to verify conformance to the external and internal 
specifications by controlling the interfaces above and below 
the interface driver. The third goal was achieved by using 
existing stress and busy-system tests. 

Implementation 

The test environment included an HP 9000 Model 720 work- 
station with an HP 25525A EISA SCSI host adapter, an HP 
1650 logic analyzer with a SCSI bus preprocessor, an HP disk 
array, several IIP 97560 1.3-gigabyte disk drives, and an HP 
Vectra PC with an Adaptec SCSI target emulator board. 

The test software modules and hardware configuration are 
shown in Fig. 1. 

User-Level Test Program. The user-level test program is essen- 
tially a test script interpreter. The program reads ASCII data 
from an input file, invokes the test peripheral device driver, 
and then whites the test results to an output file. 

An input script consists of commands and parameters to 
execute a test. The basic command is execute an 1/0 giving the 
target identifier, the SCSI command descriptor block, the 
length of the data transfer, and all the other necessary details 
as parameters. Another useful command is loop last which 
was used to repeat the previous command a given number 
of times. With this general mechanism many test cases could 
be created by just editing the input file and changing the 
parameters. The test parameters were assembled into a data 
buffer and passed to the test peripheral device driver 
through a system control (ioctll)) call. 

Additional script commands were used to perform multiple 
concurrent 1/Os, issue a SCSI bus reset, configure the host 
bus adapter, and provide special instructions to cover comer 
cases. 

On completion of a test script the test title, lest number, 
and results were written to an output file. The title and test 
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number had a one-Jo-one correspondence with ihe test 
cases in the test plan. The results included all the input pa- 
rameters as well as any return fields from the driver such as 
status, SCSI status, and the data transfer residue. 

Test Peripheral Device Driver. The test peripheral device 
driver was developed by starling with a copy of a real pe- 
ripheral device driver and adding new loctll) options that cor- 
respond to the test commands issued by the user-level test 
program. 

The test peripheral device driver receives a data buffer via 
the ioctH) call from Ihe user-level test program and is respon- 
sible for allocating kernel memory space for I/O control 
blocks and other data Structures, such as the SCSI command 
descriptor block. The primary function of the test peripheral 
device driver is to translate the input data buffer into a con- 
trol block that the SCSI driver can understand. The control 
block is then passed to the interface driver through the 
transport layer. After the transaction completes, the test 
peripheral device driver is revived when its call-back func- 
tion pointer receives control return parameters. 

All hough it seems that we could have used a real peripheral 
device driver for the above functions, we didn't because of 
liming and control. A good example is the test for exceeding 
the maximum number of SCSI queue-tagged I/Os. The test 
peripheral device driver could ensure that the SCSI driver 
was called with the correct number of I/Os to surpass the 
SCSI queue-tag limit without HP-L'X liming dependencies 
and we could do i his repeaiably. 

SCSI Target Emulator. The user-level test program and the tesl 
peripheral device driver Control the type and number of l/()s 
that the SCSI driver will initiate. On Ihe oilier end or I he- 
SCSI bus we used an Adaptec target emulator test adapter 
with Adaptec software library functions, which allow greal 
flexibility in manipulating the SCSI bus. Tesl scenarios using 
the Adaptec functions were written in the C programming 
language. The Adaptec functions provided control of each 
link-level phase of the SCSI bus so thai we could perform a 
wide range of different I/Os and exception conditions, 11 was 
necessary to synchronize the number of I/Os between Ihe 
expected behaviors of ihe host and Ihe target. However, the 
target emulator was general enough to read the lype of I/O 
and length of the data transfer out of the SCSI control block. 

Test Cases. The tesl platform described above was used to 
accomplish over !)(H) different tests using -18 test suites. 
These tests were duplicated for the SCSI DATA IN and DATA 
OUT phases. Bach test was also performed for host dala 
alignment boundaries to ensure thai data transfers were not 
page and cache aligned. Some of Ihe major lesi suites are 
lisled below: 

Save Pointers 

Restore Pointers 

Parity Errors 

Short Data Transfers 

Overrun Dala Transfers 

Synchronous Dala Transfer Negotiation 

Unexpected Disconnect 

Unexpected Phase Change 

Unexpected Message In 

I 'nexpecled Reselector 

Message < )ut Reject 



SCSI Bus Reset 
I/O Timeout Abort 
Selection Timeout 

The initial number of test cases for each suite was designed 
into the original test plan based on experience with earlier 
host-adapter software. Test cases were chosen to transfer 
data lengths on boundaries such as 0 bytes, cache line size, 
and page size. Data transfer lengths were also cycled around 
these boundaries by counting through plus and minus the 
SCSI controller FIFt ) size. 

As actual testing progressed the number of different cases in 
a test suite was increased according to the number of defects 
discovered. If the initial number of defects for a suite was 
zero we determined that the tests were adequate. If one or 
more defects were discovered the number of test cases was 
expanded. If Ihe new test cases revealed additional defects, 
the lesi rases unc expanded i" approach exhaustion. 

One area in wliich additional testing was required involved a 
special sequence of data (SCSI DATA IN or OUT) interrupted by- 
messages (SCSI MESSAGE INsi. The messages were generated 
by the Adaptec target device and caused the interface driver 
to examine or adjust its DMA pointers. The messages in- 
cluded a SCSI Save Pointers or Restore Pointers parameter. These 
parameters added complexity to the interface driver, which 
Increased the need for extensive testing. Testing revealed 
that this sequence was furt her complicated if an unexpected 
MESSAGE IN was received during Ihe SCSI DATA phase. The 
interface driver rejects unexpected messages. 

White-box analysis of the design showed that receiving two 
Of these messages in a row (separated by data) could also 
be a problem. From lliis analysis we concluded t hat a system- 
atic approach to testing for these sequences was necessary. 

The basic tesl sequence was: 

DATA - MESSAGE IN - DATA - MESSAGE IN - DATA - MESSAGE IN - 
DATA -MESSAGE IN -DATA 

The objective was to develop a lest matrix that included all 
possibilities of the basic lest sequence. The MESSAGE IN 
parameters were either Save Pointers, Restore Pointers, or an 

unexpected message in. Also, one of ihe parameters could 

repeal. The following sequences represent three of the 36 
test cases we derived. 

1 . DATA - Save Pointers - DATA - Save Pointers - DATA - Restore 
Pointers - DATA - Unexpected MESSAGE IN - DATA 

2. DATA - Save Pointers - DATA - Save Pointers - DATA - Unexpected 
MESSAGE IN - DATA - Restore Pointers - DATA 

3. DATA - Save Pointers - DATA - Restore Pointers - DATA - Save 
Pointers - DATA - Unexpected MESSAGE IN - DATA 

Examination of available literature on statistics did not pro- 
vide a convenient formula for choosing four parameters out 
of three possibilities when one of the choices could repeat. 
Empirical reasoning led to the following solution. Permuta- 
tions of three taken three at a lime (3! I equals six. Now if we 
begin each of Ihe six permutations with one of Ihe duplicate 
choices (as shown in the above sequences) we gel 18 (3 x 6) 
lesi cases. ;uid if we end each of Ihe six with a duplicate we 
end up with a tolal of .'!(> lesi cases. Each of these lesi cases 
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was also accomplished with data transfer lengths greater 
than and less than the number of bytes the host expected. 

Regression Testing. Test execution was fully automated al- 
lowing the tests to run with no intervention by the tester. 
First a master, results file was created by manually execut- 
ing and verifying the tests one at a time. The test number 
was compared to the number in the test plan and the SCSI 
bus sequence displayed on the logic analyzer was inspected 
to ensure that il matched the expected sequence. Identical 
Output was written to the display and the results file and 
these results were examined to be sure that they were cor- 
rect. This results file then became the master results file and 
was stored in a separate directory. Differences in subsequent 
test runs could be observed by comparing the current results 
file with the master results file. 

Results 

After each test in the test plan was completed successfully 
an instruction coverage analysis tool was used to measure 
test coverage. This tool was used to determine how many 
lines of code were actually executed. The analysis tool was 
only used after every test in the test plan had been com- 
pleted since it is not a good substitute for designing lest 
cases. The tool docs identify code that is never executed. 
The first time the analysis tool was used it reported that we 
covered approximately 83% of the code. The 17% of code 
that was not executed fit into roughly three classes: code 
that should have been covered by the test cases, code that 
had no corresponding test cases, and code thai required 
catastropliic hardware failure or extreme system conditions. 

For the first class we identified the test cases that should 
have caused execution of the driver code and set break- 
points to determine exactly why the code was missed. For 
some cases defects were uncovered in the driver and in 
sone cases the target emulator was not doing what it was 
supposed to be doing. These conditions were collected. 

In the second class, test cases were added to the test plan 
and implemented to cover the code not executed. Most were 
simple omissions, but a few were extremely difficult to 
cover. One case in particular required that the data transfer 
size of all outstanding I/Os be great enough to exhaust the 
system's I/O map allocation of resources and the number of 
outstanding I/Os be large enough to cause the driver to allo- 
cate a new page of memory for its data descriptors used for 
DMA parameters. The simultaneous occurrence of these 
two events required approximately three days of test effort. 
The result was worth it because when the block of code in 



question was finally executed the system went into a panic. 
The problem was traced to a member of a st met ure passed 
as an argument to an io_services routine that was not pointing 
lo the appropriate data structure, and it was only used in this 
case. In hindsight il is easy to claim that the problem should 
have been found through inspection. However, this particu- 
lar block of code was exceptional enough to merit testing. 

After adding the cases for the first two classes, the coverage 
analysis results improved to 93%. The remaining 7% of the 
code was carefully inspected and consisted of cases for ex- 
ceptions resulting from abnormal hardware conditions such 
as an unexpected interrupt from the SCSI controller and a 
bad REQ/ACK handshake on the SCSI bus. Since recovery 
from these conditions used the same code as conditions we 
were able lo test, we were satisfied with the quality of the 
test effort and its results. 
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An Architecture for Migrating to an 
Open Systems Solution 



A process and a model have been developed that provide an easy growth 
path to a client/server, open systems architecture for information 
technology applications. 

by Michael E. Thompson, Gregson P. Siu, and Jonathan van den Berg 



As we move further into the 1990s, information technology 
is undergoing rapid changes and significant challenges. 
Business decisions are evolving rapidly to meet competition 
and satisfy customers. Technology is offering more choices 
than were available in the past decade. Emerging client/ 
server technologies and competitive business needs are 
forcing information technology groups to reevaluate how 
high-quality business solutions can be delivered faster. 

HP's Worldwide Support Systems (WSS) organization is an 
information technology group that develops mission-critical t 
systems for Hewlett-Packard's worldwide customer support 
business. For the last decade, WSS has developed software 
applications using traditional technologies, tools, and 
processes. 

During the late 1980s, WSS embraced client/server technol- 
ogy to meet rapidly changing business needs. Client/server 
technology is a form of distributed computing in which ap- 
plication processing is divided between a client process and 
a server process. The interaction is simple: the client pro- 
cess initiates requests to the server and the serv er fulfills the 
request and responds to the client. This article discusses our 
experiences with developing client/server solutions using 
open systems tools and technologies. 

Open systems provides a unified approach for developing 
and managing systems, networks, and user applications, 
resulting in the ability lo run a single version of a software 
application on different hardware platforms. Because they 
communicate using standard protocols, products based on 
an open systems design can be interconnected and will 
work together regardless of whal company manufactured 
them. For a user configuring a computer system or network, 
the benefit of open systems is the freedom to choose the 
best component for each function from the offerings of 
many manufacturers. 

Our experiences began when the open system concept was 
in its infancy so we learned along with the rest of the indus- 
try. There were no clear leaders for each technology compo- 
nent required to develop a complete client/server solution. 
We believe our experiences to be extremely valuable to 
those who are considering client/server development solu- 
tions while open systems standards are being defined. 

t Mission-cniical systems are software applications that cannot bo taken offline lor an ex- 
tended period of time without adverse impact le g . order management, engineer dispatch, 
inventory control systems, etc I. 



The Early 1980s 

During the early 1980s, the primary focus of our use of in- 
formation tec hnology was to increase productivity in the 
support community through automation. Most of Hewlett- 
Packard's customer support business was organized around 
area and region business units. Each of these business units 
used HP 3000 systems as the primary, and sometimes only, 
business computer. Because these business units were de- 
centralized, transaction volume was relatively moderate. 

Our applications were designed to run on IIP 3000 comput- 
ers from block mode terminals using the VPLUS/3000 screen 
handler. Interactive dialogs were rarely used in applications. 
When communication between applications was required, a 
batch solution was usually the answer. 

Systems were designed with very little effective code reuse. 
Business edits, database access, and screen I/O were all 
mixed together into a module or program. Our technology 
choices were limited to COBOL, Image (DBMS), and the 
VPLUS/3000 screen handler (Fig. I). 

COBOL Program 



B100 EDIT-CUST0MER-INF0. 

IF SCR CLJST NUM ED BLANKS 
MOVE 110119 TO MSG-NUM 
GOTO B100-END 

If SCR-CUST TYPE E0"HP" 
M0VE 110119TO MSG-NUM 
GOTO B100-END 

B100END 

B200 ADD CUST TO DATABASE. 

PERFORM XIOOMOVESCRTOOB 
PERFORM GET-EXISTING -CUSTOMER 

IF IMAGE. RESULT EO 0 
MOVE 102344 TO MSG-NUM 
GO TO B200 END 

B200-END 

B300 EDIT- AND-A00 -CALL 

IF SCR-CALL ID NOT NUMERIC 
MOVE 109383 TO MSG-NUM. 
GO TOB3O0-ENO 

MOVE SCR-DATA TO DB DATA. 
PERFORM OBPUT. 
B300 END 



Kig. 1, Traditional architecture for Early 1980s support applications. 
This architecture consisted or a single executable program that han- 
dled its own database rails and used a forms package for the user 

Interface. 
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fbefe wore few choices, if any. for software lhal would run 
across mulliplalforru or niuliivendor hardware or software. 
Introducing new technology into this type of environment 
was rarely considered. System developers worked within a 
limited technology environment where constraints existed 
because of the HP proprietary hardware selected. 

The Late 1980s 

Into the mid-to-late 1980s, different technology choices were 
becoming more available. Business managers were asking if 
we could deliver our application systems on PCs or HP-UX* 
workstations. The HP-UX operating system, computer- 
aided software engineering (CASK) tools, object-oriented 
languages, and relational database management systems 
( RDBMS) were emerging as popular alternatives to the 
traditional technologies and tools we had used over the past 
ten years. 

We were faced with the challenge of developing a strategy to 
introduce these new technologies into our existing systems 
without any delay to our customers. This challenge forced 
us lo reevaluate our most fundamental principles of systems 
development. 

Technical Architecture 

In the fall of 1989, WSS created a technical architecture to 
provide a foundation for developing a consistent long-term 
design strategy for systems development. This architecture 
provides a common framework for designing modem, inte- 
grated client/server systems. These systems are integrated 
in the sense that they can operate and interact with other 
applications through common application program inter- 
faces (APIs) using integrated technology tools and compo- 
nents. The components of our current technical architecture 
are shown in Fig. 2. 



Technical Architecture 

togical Model Recommended 

Supporting 




Use Standards 



Stylo 



Fig. 2. The new technical architecture, 



Logical Model. This portion of the technical architecture de- 
fines a template that can be used to create or modify appli- 
cations that are compatible with the open systems concept. 
The logical model is described in more detail below. 

Recommended Supporting Technologies. Supporting technolo- 
gies include hardware platforms, operating systems, net- 
work services, languages, databases, user interfaces, and 
development environments that support the logical model. 

Recommended Tools. These are lools used by application de- 
velopers, designers, and maintenance personnel for the cre- 
ation and support of application software. Tools such as 
integrated CASE and branch flow analysis are some of the 
recommendations. 

Design and Use Standards. This part of the architecture con- 
sists of style guides, interface definitions, and practices. 
These standards define a common set of terms and a consis- 
tent framework. Style guides include items such as guide- 
lines and standards for design and coding. Practices means 
process standards such as code inspections and testing 
strategies for client/server implementations. 

In summary, this architecture has been adopted as the 
model for HP information technology, which is an internal 
IIP function responsible for developing and maintaining 
information systems applications and networks fot organiza- 
tions such as marketing, support, and accounting. The archi- 
tecture is constantly being revised as new technologies, 
tools, standards, and other methodologies become available. 

The technical architecture enables an application designer to 
define an application In terras of the logical model compo- 
nents, select the technologies needed lo support the applica- 
tion, select specific tools for implementing the design, and 
follow design standards so that I he application will have a 
common look and feel and be able to interact consistently 
with other applications. 

Logical Model 

The logical model shown in i"ig. 3 is a definition or template 
of how an application can be partitioned for an open sys- 
tems solution. It is a framework thai organizes all applica- 
tions into five components: user interface, user task logic, 
business transaction logic, data manager, and environment 
manager. This model is a good basis for researching and 
recommending open systems strategies for application de- 
velopment. In addition, it defines a framework for sirategies 
relaling to application migration and third-party purchases. 
Finally, this model does not imply any specific technologies 
or client/server configuration because these decisions are 
made in other parts of the technical architecture. 

User Intedace. The user interface provides the user's view 
into a business application, and manages all communication 
between the user and the application. It is responsible for 
painting the "picture" the user sees and collecting user in- 
put. It constructs dialogs by presenting tlata or choices and 
requesting selection, data input, or other responses. 
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Fig. 3. The logical model for open-systems design. 

A good example of a user interface is the automated teller 
machine, or ATM. w hich is used for automated banking 
transactions. The ATM provides an interface thai enables a 
user to perform a bank transaction. The interface itself is 
mostly idle. However, it will interact with the user by pre- 
senting data such as accounts and balances, and requesting 
selections such as withdrawals or deposits. 

User Task Logic. The user task logic drives the user interface 
and invokes the appropriate business transaction process- 
ing. Understanding the results of user requests and commu- 
nicating them to the user interface (where the results are 
displayed ) are also the responsibilities of the lask logic- 
layer. For example, in t he ATM example, when the user se- 
lects an option (such as withdrawal), the ATM application 
(client ) formulates a request to the bank account manage- 
menl application In perform I he withdrawal. The ATM ap- 
plication waits for a response from the aceounl manage- 
ment application. Formulating the request to the bank 
amplication and communicating the response lo ihe user 
interface are task logic functions. 

Environment Manager. Tins component is responsible for 
managing communication between Ihe other four compo- 
nents of the logical model. Communication responsibililies 
include connecting two components (dynamic and static 
connections), overall management of application layer 
instances, and communication from one clicnl/server instal- 
lation lo another. For example, in the ATM model, the envi- 
ronment manager allows clients to transfer funds from one 
banking establishment lo other banking establishments. 

Business Transaction Logic. The business transaction logic 
ciraii's, deletes, updates, and retrieves business data. It im- 
poses business policy or rules upon the dala. Transaction 
and data access security is managed in this layer to control 
authentication of the user requesting the transaction. 

After Ihe user presses "OK" on Ihe ATM user interface, the 
lask logic will transmit the withdrawal requesl lo Ihe bank- 
ing application. The requester of the Iransaction is validated, 



the withdrawal request is edited, and account balances are 
checked. These are all functions performed by the business 
transaction logic. 

Data Manager. This layer manages the physical storage of 
data, and provides read and write access to the data. It man- 
ages concurrent access by multiple users (business transac- 
tions). It is responsible for ensuring the physical integrity 
and recovery of data In the ATM example, the banking ap- 
plication receives requests from many users at one time. 
The function in the banking application that updates the 
user's account with the withdrawal information and locks 
the account until the withdrawal is completed is located in 
t he data manager. 

Client/Server Architecture 

The five components of ihe logical model are intercon- 
nected through message-based interfaces that allow the 
components to be separated physically into a client/server 
configuration. Fig. 4 shows an overview of QUI client/server 
architecture. Applications are organized into a client, a 
server, and a client/server interface. The client, which con- 
sists of the user interface and user task logic, deals with 
presenting and managing data for users. The server, which 
consists of business transact ion logic and the data manager, 
deals with managing the business data and enforcing busi- 
ness rules and policies. Finally, the environment manger 
provides the client/server interface, which is a iransparent 
network linkage between client and server. 

Migrating Existing Systems 

To lesl the feasibility of the technical architecture, we used 
it on two existing production applications. The first project 
consists of 1(1(1.(100 lines of code and is used lo dispatch and 
manage software-support serv ice calls for HP's customer 
response center. This project was a step-by-step migration 
from Ihe traditional application code architecture (shown in 
Fig. I ). which typically dispersed lask and business logic 
throughout Ihe application. (" the client/server structure 
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Fig. 4. The client/server logical model. 
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defined by Ihp technical archil enure. The original applica- 
tion ran in an IIP 3009 MPE operating system environment 
and consisted of an Image database, COBOL application 
code, and VPLL'S/3000 online access code. The new client 
application uses a graphical user interface and runs on HP 
9000 Series 300 and 100 machines in an IIP-I X operating 
system environment. The server portion of the application 
runs in native model on an IIP 3000 Series 900 machine 
running in an MPE/iX operating system environment. 

One of the objectives of this migration was to salvage as 
much of the original application as possible while re-engi- 
neering the technical infrastructure. The existing COBOL 
code was a mixt ure of online code and database access op- 
erations. We took the following steps in migrating the old 
application to the new client/server architecture: 

1. We evaluated existing code to determine which database 
access operations should be combined with application 
edits to ensure the same data integrity and performance. 

2. The results from step 1 were encapsulated in a predefined 
interface which became the single access path for all exter- 
nal processes (clients and other batch applications). This 
portion of the application is the server in the client/server 
logical model. 

3. We evaluated the existing code again to determine the 
online application logic that had to be reengineered to run in 
a new hardware and software environment. This environment 
included an HP 9000 Series 300 or 400 running the HP-UX 
operating system and a graphical user interface based on 
OSF/Motif. This portion of the application is the client in the 
client/server logical model. 

4. The connectivity component that enabled the application 
component from step 2 to interact with the application com- 
ponent from step 3 was designed and developed. This por- 
tion of application and other supporting software represents 
the environment manager in the client/server logical model. 

Fig. 5 shows the components of the new system encapsulated 
in the client/server model. 

The technical architecture helped to describe the division of 
responsibilities between the client and the server. The biggest 
impact the architecture had was in determining the location 
of the network. The logical model does not prohibit an ap- 
plication from introducing a network between any two layers. 
However, the client/server view of the logical model recom- 
mends splitting the application with a network between the 
user task logic and the business transaction logic. 

The second project involved the development of a new 
client application with a graphical user interface that runs 
on HP 9000 Series 300 and 400 machines and a server ap- 
plication that runs in native mode on an HP 3000 Series 900 
machine. This application configures and prices support 
products for HP's customer support business. The project 
consisted of approximately 40,000 lines of code. 

The success of these two projects proved that the technical 
architecture, particularly the logical model, provided us with 
a framework for migrating our installed base of applications 

t Native mode implies thai a machine is using its own capabilities (capabilities mheienl to 
the machmel as opposed to compatibility mode, in which a machine is emulaling another 
machine 
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Fig. 5. The customer call tracking system after migration. 

to new hardware and software platforms and developing 
new applications. 

Process Learning Experiences 

Despite the success of the t wo projects mentioned above, 
both projects exposed areas where we needed some im- 
provements in both process and technology. 

Business Transaction Design Time. Defining appropriate busi- 
ness transactions requires a lot of work at the beginning of a 
project. However, investing this extra time helps build a 
foundation for the rest of the application design. Once these 
transactions are defined, development teams can work in 
parallel. 

Business transactions provide the interface between clients 
and servers. If the transactions are designed properly, cli- 
ents will be able to communicate with any server (aside 
from security restrictions) using the business transactions 
defined for it. The design of either the client or the server 
can change without affecting the other as long as the busi- 
ness transaction rules or the transactions themselves are 
preserved. New clients can easily be added to any server by 
simply using the relevant transactions. Therefore, mainte- 
nance is decreased and reusability is increased. In addition, if 
business transactions are defined correctly, network traffic 
will be reduced. 
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During the call tracking project, we spent only 10% of our 
design, code, and test time working on business transaction 
design. However, with the configuration and pricing project, 
we invested approximately 50% (if our initial work on the 
transaction definition. These transactions defined our ap- 
plication more concisely, which gave us better results and 
less rework as the project progressed. 

Use ol Information Engineering. The technical architecture 
provides one of the building blocks for application develop- 
ment- However, to meet certain business needs and improve 
the development process, parallel efforts such as usability 
engineering, performance engineering, and information 
engineering are recommended. 

We spent a lot of time reworking the transaction definitions 
and code for the call tracking project because we did not do 
a thorough analysis of the problem. Using information engi- 
neering techniques in the beginning of the project can save 
lime and effort. Information engineering provides a struc- 
tured methodology and guidelines for discussing the how, 
what, and where aspects of development. The how relates 
to the processes in the application, the what is the data the 
applications use, and the where refers to the location of the 
solution ( in hardware or software). 

Use of Data Flow Diagrams. 1 hiring the configuration and 
pricing project, we used data flow diagrams ( DFDs) and 
Structured analysis and structured design techniques to help 
represent the flow of data among the modules of the pro- 
gram. This enabled us to address critical elements during 
transaction definition. Data How diagramming is the link 
between the analysis and design phases of information 
engineering. 

Increase Training Time. Migrating the call Hacking application 
was among the first client/server projects for IIP informa- 
tion technology. Because the client/server model brought a 
new environment to IIP information technology, users and 
developers had to become proficient in new skills and a new 
way of thinking about organizational relationships, applica- 
tions, processes, and technology. The learning curve for both 
our developers and our users was substantia]. We spent more 
time training our developers, and did not spent I enough lime 
training our users. The amount of time needed to train our 
users was significantly underestimated. This greatly in- 
creased our acceptance risks during the implementation 
phase of the project. 

Consider Performance Needs. We focused our efforts more on 
network performance than client performance, which later 
became an issue. Client performance includes the response 
time from one logical task (such as selecting help, making a 
menu choice, or editing a dialog box ) to the next logical 
task. The client application is driven by the end user and 
therefore must perform according to end-user expectations. 
Thus, the performance needs of users need to be considered 
so developers can balance new development tools and re- 
quirements with the hardware platforms that users demand. 

Correct Hardware and Software Infrastructure. The expense of 
migrating to a client/server environment should be consid- 
ered. While migrating our applications, we discovered that we 
did not have the correct hardware and software infrastruc- 
ture in place. We neetletl high-speed networks which were 



not available at all sites. This limited our communication 
capabilities. In addition, we still used old hardware that had 
memory limitations. This limited our ability to incorporate 
new technologies, causing performance problems. 

Adopt a Migration Plan. Migrating from a traditional (terminal, 
host-based applications) architecture to a client/server ar- 
chitecture can be approached in phases. Existing databases 
should be surrounded with a server shell. Clients can com- 
municate with servers using properly designed business 
transactions. This client/server separation allows the data- 
base to be replaced later without replacing the client. L'nnu- 
grated applications can be integrated on the users work- 
station, using terminal emulation, until they are migrated to 
a new platform. 

Technology Lessons Learned 

Besides the process improvement lessons described above, 
we also learned some lessons about the technical architec- 
ture and our design model. 

Adopt a Technical Architecture. Today, internal customers de- 
mand multivendor network connectivity providing standard- 
ized application services. Open systems will allow selection 
from a wide range of multivendor solutions. Although open 
systems standards are still evolving, adopting a technical ar- 
chitecture will help provide guidelines for selecting technol- 
ogies and tools that support open systems. This reduces the 
risk of locking application developers into a vendor-specific 
framework of technologies, tools, and processes. As stan- 
dards become defined or new technologies are introduced, 
migrating to open systems will be much easier. 

Defining and standardizing interfaces allows application 
logic to be independent of technology. The API is a standard 
library of functions that separates the user from the underly- 
ing technology. Because an API can be used to encapsulate a 
technology, changes within the encapsulation can occur 
without affecting application code. For example, technolo- 
gies (tools) providing the interface to a database can change 
without impacting the business transaction logic. 

Our migration strategy required interfaces between clients 
and servers to be standardized, normalized, and portable. For 
example. HP's response center lab developed a network API 
called TVAL (tagged values), for interprocess communication 
between HP-UX and MPE/iX operating systems. This API 
will protect our investment during migration from NellPC 
to an open systems product such as Network Computing 
System (NCS). 

Develop a Business and Data Model. Implement a model in 
provide a description of the business that is going to be sup- 
ported. This model will document what processes the busi- 
ness needs in meet its goals, and what information is needed 
for each process. Once this information is determined, de- 
velop a data model to provide consistent definition and in- 
terpretation of the data wherever it is used, and of business 
rules that determine its integrity. This will allow different 
applications to be consistent and to interact successfully. 
The objective is to manage data so that it is defined only 
once, although it may be used by multiple processes or ap- 
plications (clients) and physically stored in several locations 
(servers). 
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Develop Data Security. As we migrate to an open systems envi- 
ronment, customers from outside HP will be able to access 
our systems. In our current environment, systems only check 
for valid identification and authorization. Standards groups 
are working to establish a Distributed Computing Environ- 
ment ( DC'E) that includes security services. DCK is a com- 
prehensive, integrated set of services developed and spon- 
sored by the Open Software Foundation (OSF) which 
supports the development, use, and maintenance of distrib- 
uted applications. DCF. supports transparent connection and 
communication of any object (client or server) within a dis- 
tributed networked environment. 

Benefits 

While developing and migrating our applications, we also 
discovered some unexpected benefits. 

Development Team Independence. Splitting applications into 
client, server, and communication components encourages 
application development across organizational boundaries. 
Thus, applications can be developed in parallel, which de- 
creases the time to market. The call tracking project was 
developed by two different development teams in HP's sup- 
port organization. This allowed the teams to be managed 
separately while I he application was being developed simul- 
taneously. The configuration and pricing project teams were 
also split between client, server, and communication logic. 
After defining the various APIs (communication, error han- 
dling, and data buffer) between the client and the server, 
each team was able to develop and lest its part separately. 
The teams worked independently and did not need to be 
concerned with the internals of the other components. The 
three parts were brought together successfully during 
integration testing. 

Lower Maintenance and Higher Quality. Both projects greatly 
simplified maintenance. We noted that most service requests 
associated with the the initial release of two products were 
for changes to client behavior, not business logic. Because 
the User task logic (client) is separate from the business 
transaction logic (server), the amount of code to be reviewed 
before a change can be implemented is greatly reduced. This 
allowed us to estimate schedules easier and have faster 
turnaround for application change requests. Lastly, the de- 
velopment teams became familiar with the application 
quicker because they did not have to learn both the user 
task logic and the business logic. 

Since their initial release both projects have exhibited a very 
high quality. In addition, the application teams consisted of 
eight to ten people for the initial release and only one to two 
people during the subsequent releases. 



Improved Application Testing. Server testing was automated by 
defining a single interface to the sell er. We developed a lest 
driver that could send predefined test cases, capture server 
responses, and compare them with expected results. We 
developed 25(10 reusable server test cases. This accomplished 
about 90% of our unit testing. In addition, the complete lest 
for the server takes only two hours, allowing a full regres- 
sion lest suite to be run whenever liie server is changed. 
This allows the team to perform verifiable regression tests 
quickly as needed. 

Conclusion 

Developing a client/server solution using an open systems 
design strategy provided several learning experiences. These 
experiences included leveraging current investments of 
hardware, software, and personnel, choosing the right prod- 
ucts and standards to integrate software, avoiding software' 
and hardware lock-in, and incorporating new technologies. 

The technical architecture provides a framework for decid- 
ing which technology and tools lo use for client/server de- 
velopment. Once this architecture is defined, migrating and 
developing applications to the client/server paradigm can 
be accomplished without completely rewriting existing 
applications. 

In addition, developing client/server applications using the 
open systems concept means that a development environ- 
ment can be tailored to meet Specific business needs. This 
minimizes the risk of locking developers into specific hard- 
ware and software platforms and processes. Resources can 
be spent on designing the best combination of existing and 
new components. 

Finally, we have found thai the technical architecture de- 
scribed in this paper will work because it provides an open 
systems solution, offering a simple migration path to a client/ 
server architecture. 
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^PLj | , on the design and develop- 
^ r -~^ ment of the DraftMaster 



computer science in 1981 from Barcelona Autono- 
mous University and his MS degree in computer sci- 
ence m 5988 from George Washington University 
Before joining HP he was a software developer for 
the Generalitat Health Department and the World 
Bank He's a member of the ACM and is interested m 
computer graphics Carles is married and has two 
daughters. He was bom in Granoliers. Spain and 
enjoys mountain biking. 

56 Multiprocessor HP-UX 

Kyle A. Polychronis 

^^^H^^^^^H Kyle project 

I terns Software Division. He 
^^^^ W L iNel- 

H-7*« * >■ works Division in 1983 85 a 
1 software engineer, working 

it on the Turbolmage profiler 

'^B and then the HP-UX kernel 
^ He then served as project 

manager for the HP-UX kernel and the multiprocessor 
adaptation of HP-UX for release 8.06 He was a con- 
sulting project manager for the HP corporate engineer- 
ing software initiative, and is now project manager for 
HP-UX open systems I/O Kyle's professional interests 
are operating systems, software engineering tech- 
niques, and database systems He received Ins BS 
degree in computer science from the University of 
Utah in 1979 and his MS degree in computer science 
from the University of California at Berkeley in 1980 
Before coming to HP he developed database-oriented 
UNIX applications for the telecom industry at Bell 
Laboratories A native of Salt Lake City, Utah, he is 
married and enioys hiking, camping, music, and 
gourmet food and wine 

Douglas V. Larson 

Software development 
engineer Doug Larson |omed 
HP's Data Systems Division 
in 1979 He worked on the 
RTE operating system until 
1983, then joined the HP-UX 
kernel lab. now part of the 
Open Systems Software 
Division For the multipro- 
cessor HP-UX 8.06 operating system, he was respon- 
sible for process management and system perfor- 
mance Born in Minneapolis, Minnesota, he served ill 
the U S. Navy for six years, attaining the rank ol petty 
officer first class, and attended Ihe University of Min- 
nesota Institute of Technology, receiving a BS degree 
in computer science in 1978. Belore joining HP, he did 
scientific programming for the University of Minnesota 
and the U S Bureau of Mines. Doug's interests in- 
clude go (he's a three-dan player), live theater, and 
ballroom dancing. 




Plus user interlace Carles received his BS degree in 
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Farid Matta 

Since joining HP m 1981. 
Fand Maria has been in- 
volved m various phases of 
advanced integrated-circuit 
processing, testing, and 
packaging He served as a 
fc* / \ process engineering man- 
/^^M ager for NMOS and CMOS 
■ IC manufacturing, as a proj 
ect leader developing the membrane probe test tech- 
nology, and as a project manager for the develop- 
ment of the DTAB packaging technology. Currently, 
Farid is a project manager with HP Laboratories, 
working on the development of new measurement 
instruments He is an author or coauthor of over 30 
technical publications and is coauthor of a book on 
electrical contacts and interconnects published in the 
USSR in 1974 He is named as an inventor in five 
patents and is a member of the IEEE and the IEEE 
Components, Hybrids, and Manufacturing Technology 
Group. Before joining HP, he worked on bipular IC 
fabrication at Advanced Micro Devices, and was an 
assistant professor at the Institute of Electronics in 
Menouf, Egypt. He received his BSEE degree in 1965 
and his PhD degree in microelectronics in 1972 from 
the Leningrad Institute of Electrical Engineering Farid 
was born in El-Menya, Egypt He is married, has a 
son, and enjoys painting, art history, and hiking 

78 EISA for HP 9000 



Vicente V. Cavanna 

Vince Cavanna is an 
engineer/scientist at HP's 
Systems Technology Division, 
specializing in high-speed 
digital design, synchrnniza- 
tion. and electromagnetic 
rBj^L i compatibility (EMC) He 

for the HP EISA cards and 
consulted on the implementation of the EISA subsys- 
tem for the HP 9000 Series 700 workstations Born in 
Manila. Philippines. Vince received his BSEECS degree 
(19741 and MSEECS degree (1976) from the University 
of California at Berkeley He joined HP's Automatic 
Measurements Division in 1976 The proiects he has 
worked on include the HP 2240/50 measurement and 
control processor, HP Fiber Link, and various back- 
plane interface chips for channel I/O and HP precision 
bus backplanes. His work has resulted in a patent on 
an LED driver for a high speed fiber optic transceiver 
and a joint patent on a FIFO-based synchronizer that 
is used in various HP products Vince is married and 
has four children. He is a table tennis tournament 
player, as well as a soccer player and coach, and he 
enioys reading, gardening, and woodworking. 





Christopher S. Liu 

Chr>s Liu is a hardware 
development engineer ai 
HP's Roseville Networks 
Division He joined HP in 
198" after receiving his 
BSEE degree from the Uni- 

I wif^Hm^^M versrtv D ' tne Pacific ,haI 
I same year. At present he is 

working on network inter- 
faces for printers and plotters. For the HP EISA proj- 
ect he worked on the hardware development of the 
HP EISA HP-IB card Before the EISA project, he 
worked on HP precision bus development tools and 
before that he worked as a manufacturing develop- 
ment engineer on HP 9000 I/O interfaces Before 
coming to HP. Chris was a co-op student at NASA 
Ames Research Center where he worked on the con- 
trol system for a laser-based velocity measurement 
system His work at HP has resulted in a pending 
pateni for dynamically configurable interface cards 
with variable memory size Born in Lodi, California, 
he is married, and his interests include bicycling, ski- 
ing, Softball, and golf He also enjoys carpentry and 
reading 
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David S. Clark 



After receiving a BSEE 
degree from California State 
University at Sacramento in 
19B6. David Clark joined 
HP's Roseville Networks 
Division He is currently a 
hardware engineer with HP's 
Systems Technology Division 
and is working on high- 
speed networks, as well as completing his MSEE 
degree at California State University ai Sacramento 
Since joining HP. he has worked on HP precision bus 
1/0 interfaces and the HP EISA programmable serial 
interface card He is listed as an inventor on a pend- 
ing patent for the HP EISA bus master. Born in Tokyo. 
Japan, David enjoys gem cutting (faceting), cabinet- 
making, running, and learning to play the piano. 

Andrea C. Lantz 

A graduate of the University 
of Delaware with a BSEE 
degree (1985) and the Uni- 
versity ol California at Davis 
with an MSEE degree 
(1988), Andrea Lantz joined 
HP's Roseville Networks 
Division in 1988. As a hard- 
ware development engineer, 
she designed hardware and application software for 
HP precision bus hardware tools that are used m PA- 
RISC machines She also worked on the hardware 
design and development for the HP EISA program- 
mable serial interface card At present, she is a man- 
ufacturing development engineer responsible for HP's 
JetDirect products. She has published four papers on 
LAN access protocols As a career guidance chair for 
the Sierra Foothills section of the Society of Women 
Engineers she works at encouraging high school and 
college students to become engineers Born in Wil- 
mington. Delaware. Andrea is married and enjoys 
music, hiking. Softball, and trying to play golf. She is 





also an the adjunct faculty of the National University 
in Sacramento. California, where she teaches classes 
m the computer science department. 

Christopher S. Liu 

Author's biography appears elsewhere in this section 
Thomas E. Parker 

Tom Parker came to HP's 
Computer Support Division 
as a summer intern In 1981 
Starting as a production 
technician, he later became 
a production engineer He 
received his BSEE degree 
from California State Univer- 
sity at Sacramento in 1983 
and joined HP's Roseville Networks Division as a de- 
velopment engineer He was the hardware design 
engineer for the HP EISA SCSI card A native of Sac- 
ramento, California, Tom is married and has three 
children He enjoys playing golf and soccer and 
contributes time as a youth soccer coach 

Joseph H. Steinmetz 

^ A graduate of California 

^l^V^^i- State University at Chico 

«— "jf B * with a BS degree (19881 in 
I9 |il computer engineering, hard- 
er a- wa,e en y' ineef J° e Stein- 
■f met? joined HP's Roseville 
Networks Division in 1988 
Joe contributed to the devel- 
opment of the HP EISA SCSI 
card for the HP 9000 Series 700 workstations. Some 
of his previous assignments have included develop- 
ing SCSI 1/0 cards for HP precision bus and channel 
1/0 SCSI, and backplane ASICs for other HP 9000 I/O 
interfaces He is currently listed as a coinventor in a 
pateni application for a coprocessor supporting archi- 
tecture for a processor that does not natively support 
coprocessing. Born in Gilroy, California, he enjoys 
mountaineering, rock climbing, running, and biking 
when not pursuing his professional interests in ASIC 
design tools, simulation, and synthesis 
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Bill Thomas 



ft 



A member of the technical 
staff at HP's Systems Tech- 
nology Division, Bill Thomas 
worked on the design and 
implementation of the test 
software for the HP EISA 
SCSI card for the HP 9000 
Series 700 workstations. 
After receiving his BSEE 
degree from the University of California at Berkeley 
in 1969. he joined HP's Loveland Instrument Division 
in Loveland. Colorado, and completed his MSEE de- 
gree work at Colorado State University in 1972 Dur- 
ing his career with HP, he has worked on software 
and hardware design for IC test systems, test system 
software for the HP 1000 Automatic Test System, 
thick-film substrates, IC design for the HP 9866A 
thermal printer, design and implementation of the 
HP-IB channel I/O interface, and diagnostic and self- 
test software for the SCSI channel I/O interface He 
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>s a member of the IEEE His professional interests 
include software, hardware, and firmware interfaces 
between host systems and per ipherals. as well as 
software reuse and object-oriented programming Bill 
'$ married and fias three children He is an active 
member of two amateur radio emergency groups m 
Sacramento. California, and is a judge for California 
applicants seeking national science scholarship grams 
His hobbies include cabmetmaking and camping 

Alan C. Berkema 

Software development 
engineer Alan Berkema at- 
tended California State Uni- 
versity at Sacramento where 
he received his BS degree in 
computer science and sys- 
tems software in 1984 The 
next year he joined HP's 
Roseville Networks Division 
Currently, Alan is working on a high-speed mass stor- 
age I/O adapter For the HP EISA SCSI project, he 
helped design and edit the interface specification and 
all test software for the interface driver Before the 
EISA SCSI project, he worked on the SCSI channel I/O 
host adapter firmware. Born in Djakarta, Indonesia. 
Alan served four years in the United States Air Force 
as a computer technician, attaining the rank of ser- 
geant He is married, has one daughter and enjoys 
jogging, fishing, and camping. 

Eric G. Tausheck 

~~ " Eric Tausheck is a develop- 
ment engineer at HP's Sys- 

W'» He joined HP's Roseville 

Networks Division m 1980 

P- . after receiving a BS degree 
f < in information and computer 
_ 1 | science from the University 

of California at Irvine that 
same year Presently, he is working on high-speed 
adapter design and the associated interface driver 
He designed and implemented the hardware-specific 
portion of an interface driver for the HP EISA SCSI 
card Other projects he has worked on include firm- 
ware implementation for the HP-CIO (channel l/0| 
HP-IB and HP-FL adapters, the HP precision bus and 
interface driver designs, and specifications for HP 
designs based on the NCR 53C700 chip family. His 
mam professional interest is high-performance I/O 
system design Born in San Lorenzo, California, Eric 
enioys time with his wife and two children 



Brian D Mahaffy 

- • - -eiop- 

Bi^^^H// ville Networks Division 

Wr American River College in 

^ BS degree m computer engi- 

neenng from California State University at Sacramento 
m 1989 He worked on implementing the I/O depen- 
dent code for the HP EISA SCSI project Currently, he 
is working on hard-copy interconnect network inter- 
faces. Past projects include SCSI channel I/O, HP 
3000 CPUs, and I/O interfaces for HP 1000 computer 
systems A native of Sacramento. California. Brian is 
an active member of the Sacramento County Radio 
Amateur Civil Emergency Services (RACES), which 
provides service during natural disasters and other 
emergencies as part of the U.S. Civil Defense net- 
work. Brian is married and has one child lanother is 
expected soon) His hobbies include ham radio and 
radio-controlled aircraft 
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Michael E. Thompson 

Mike Thompson is a produc- 
tivity and quality manager at 
HP's Worldwide Customer 
Support Operation IWCSO) 
and has served as a project 
manager for various soft- 
ware support applications 
developed at WCS0 He 
presently manages technical 
architecture implementors and quality engineers in 
the worldwide support systems group in WCSO A 
native of Las Cruces, New Mexico, Mike received his 
BBA degree in management information systems 
(1983) and his MBA degree (1985) from New Mexico 
State University. Before coming to HP in 1985. he 
was a consultant for Arthur Andersen S Co. 




Gregson P. Siu 

Gregson Siu is a technology 
quality section manager at 
HP's Worldwide Customer 
Support Operation He 
joined HP in "982 He was 
the project manager for the 
sever portion of the cus- 
tomer order tracking system 
m described in the article li- 

the past he has worked as a development engineer for 
HP's order management system, a project manager 
for a field resource management system, and a pro- 
ductivity manager for the worldwide support services 
group in WCSO He was born in Honolulu. Hawaii, 
and received his BBA degree in management infor- 
mation systems from the University of Hawaii in 
1982 

Jonathan van den Berg 

Jon van den Berg is an infor- 
mation technology architect 
in HP's Worldwide Customer 
Support Operation IWCS0I 
He served as a technology 
architecture manager for the 
client/server projects de- 
scribed in his article. After 
receiving a BBA in manage- 
ment information systems from California Polytechnic 
Institute at San Luis Obispo in 1984, Jon came to 
HP's Computer Support Division that same year as a 
software engineer. He has worked as a development 
engineer, project manager, and technical architect for 
various projects at WCSO Before coming to HP, Jon 
was an MIS analyst for IBM Corporation. Born m 
Annapolis, Maryland, he is married and has one 
child. His professional interests are object-oriented 
analysis and design and integrated development en- 
vironments. His hobbies and interests include U.S. 
amateur soccer. British sports cars, and California 
open-space parks 
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Part 1: Chronological Index 



February 1932 

Low-Cosl. 100-MHz Digitizing Oscilloscopes, Robert A Wilte 

A High-Throughput Acquisition Architecture for a 100-MHz Digitiz- 
ing Oscilloscope, Matthew S. Holeomb unit Daniel P. Timm 

Sample Rate and Display Kate in Digitizing Oscilloscopes 

A Fast, Huili-hi Test System lor Oscilloscope Manufacturing, Stuart 
O. Halt anil Jay A. Ale.rii mler 

Verification Strategy 

Stimulus/Response Delect Diagnosis in Production 

Measuring Frequency Response and Kffeclive Bits Using Digital 
Signal Processing Techniques , Martin 11. Grove 

Calculating Kffeclive Iiils from Signal-To-Noise Ratio 

Mechanical Design of the HP 54600 Series Oscilloscopes, Robin P. 
Yerqenson ami Timothy A. t'igge 

EMC Design of the HP 54600 Series Oscilloscopes. Kenneth I). 
Wynlt 

Digital Oscilloscope Persistence . James A. Kahkoska 

A High- Resolution, Multichannel Digital-to- Analog Converter for 
Digital Oscilloscopes, Givseenor H. Garnet! 

Using the High-Resolution, Multichannel DAG in the HP 54G01A 
Oscilloscope 

Comparing Analog and Digital Oscilloscopes for Troubleshooting. 
Jerabt B. MVrphy 

An Introduction to Neural Nets. John MeShane 

Design Challenges for Distributed LAM Analysis, William W. 
C rand all 

Poor Network Partitioning 
April 1992 

VXIhus: A Standard for Test and Measurement System Architecture. 
Lawrence A. DesJardin 

The HP VXlbus Mainframes 

V'Xlbns Terminology 

The VXlbus From an Instrument Designer's Perspective. Steven J. 
.Xarciso and Gregory A. Hill 

Examples of Message-Based VXlbus Instruments 

Small. Low-Cost Mainframe with a Register-Based Interface 

Design of Mainframe Firmware in an Open Architecture Environ- 
ment, Pom/ K Worrell 

Real-Time Multitasking of Instruments Ui the VXlbus Command 
Modules. Christopher P. Kelly 

VXI Progranuning in C. Lee Atch ison 



Achieving High Throughput with Register-Based Dense Matrix Relay 
Modules, Sam S. Tsui and James B. Dim- 
Mass Intercoiuiect for VXlbus Systems. Citlein L. Eriekson 

A Manufacturing-Oriented Digital Stimulus/Response Test Instrument. 
Da rid P. Kjosness 

Digital Test Development Software for a VXlbus Tester, Kenneth A. 
Ward 

The VXlbus in a Manufacturing Test Environment, Larry L. Carlson 
anil Wayne H. Willi* 

The Peak Power Analyzer, a New Microwave Tool. Dieter Selterer. 
William E. Slrasser. James D. McVey, anil Wayne ,M, Kelly 

Multilayer Shielding Protects Microvolt Signals in High-Interference 
Environment 

GaAs Technology in Sensor and Baseband Design, Michael C. 
Fischer, Michael J. Sehoessow, ami Peter Tony 

Harmonic Errors and Average versus Peak Detection 

Automatic Calibration for Easy and Accurate Power Measurements. 
David L. Barnard, Henry Black, and James A. Thalmann 

Testing the Peak Power Analyzer Firmware 

An Advanced 5-H/.-lo-5()0-MHz Network Analyzer with High Speed, 
Accuracy, and Dynamic Range. Koichi Yariagawa 

A High-Performance Measurement Coprocessor for Personal Com- 
puters, Mike Moore and Erie N. Gullerud 

Measurement Coprocessor ASIC 

Measurement Coprocessor History 

June 1992 

HP-UX Operating System Kernel Support for the HP 9000 Series 700 
Workstations. Karen Kerschen and Jeffrey R. Glasson 

An Example of the FTEST Instruction 

Providing HP-UX Kernel Funclionalily on a New PA-K1SC Architec- 
ture, Donald E. Bollinger, ['rank P. Lemnwrt, and Dawn L. Yamine 

New Optimizations for PA-RISC Compilers, Robert C. Hansen 

Link-Tune Optimizations 

HP 9000 Series 700 FORTRAN Optimizing Preprocessor, Robert A. 
Gottlieb, Daniel J. Magenheimrr, Sue A. Meloy, and Alan C. Meyer 

Vector Library 

Register Reassoeiation in PA-RISt ' ( Compilers, Valsa Santhanam 

Software Pipelining in the PA-RISC Compilers, Sridhar 
Ramakrishiian 

Shared Libraries for HP-UX, Gary A. Coutant and Michelle A. 
Ruscelta 
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Deferred Binding. Relocation, and Initialization of Shared Library 
Data 

Integrating an Electronic Dictionary into a Natural Language Pro- 
cessing System. Diana C. Roberta 

Application of Spatial Frequency Methods to Evaluation of Printed 
Images. Dole D. Russell 

Parallel Raytraced Image Generation. Susan S Sparh and Ronald 
W. Pulteyblank 

August 1992 

Midrange PA-RISC' Workstations with Price/Performance Leader- 
ship. Aik/cpic •/ DpBnels ami Kathleen ,\f. Wlieeler 

HP 9000 Series 700 Workstation Firmware 

VLSI Circuits for Low-End and Midrange PA-RISC Computers, ( ring 
.4. Glcasou, Leilh Johnson, Steven T. Mangelstlnrf, Tlmmas O. 
Meyer, and Murk A. Forsyth 
PA-RISC Performance Modeling and Simulation 

ECL Clocks for High-Performance RISC Workstations. Frank ,1 
Let tang 

IIP MOO Series "(H) Input/Output Subsystem, Daniel Li ami Andrei/ 
B. Gore 

Design Verification of the IIP 9000 Series 700 PA-RISl ! Workstations. 

Alt M. Ahi, Gregory D. Burroughs, Audrey B. Gore, Steve w. 

La Mar, Ghi-Yen R. Lin, n nil Alan L. Wieinmin 
HP Standard PA-RISC Test Programs 
Simulation Toolset 
Debugging Tools 
Metrics 

Mechanical Design of the 1 IP 9000 Models 720 and 7:10 Work- 
stations, Alien /.. Roesncr mid John P. Hop/ml 

Meeting Manufacturing Challenges for PA-RISC Workstations. 
Spencer M. Ure, Kevin IV. Allen, Anna M. Hargis, Samuel K. 
Hamuli'! anil PtUli Roeber 

High-Performance Designs Tor the Low-Cost PA-RISC Desktop, 
( 'mil/ R. Frink, Ruberl J. Hammond, John A. Di/kstul. ami Don V. 
Sottis. Jr. 

Low-Cost Plain-Paper Color Inkjet Printing, Daniel A. Keaii and 
Michael S. Ard 

Thermal Inkjet Review, or How I >o Dots Get from the Pen lo Ihe 
Page? 

Ink and Print Cartridge Development for the IIP DeskJet f>(H)C/Desk- 
WriterC Printer Family. Craig Mate, Lorcn S, Johnson, Daniel A. 

Keaii ami James p shields 

Color Science in Three-Color Inkjet Print Cartridge Development 
Making HP Print ( 'artridgcs Safe for Consumers Around Ihe World 
Automated Assembly i>r the IIP DeskJet r>(H)( VDeskWriler C Color 
Print Cartridge, bet S. Mason mid Mark ('. Until 
Color Inkj<'t Print Cart riilge Ink Manifold Design 
Adhesive Material and Equipment Selection for the IIP llcskJel 
6Q0C/Desk Writ er C Color Print ('art ridge, Douglas .1 Rial ami 
Terry M. Lumbrighl 

Machine Vision in Color Print Cartridge Production, Mirhmi J 
Monroe 

IIP DeskWrilerC Pnnter Driver Development, William J Alh-n, 
Tntii D. Conrvilli; mid Steven <> Miller 

An Interactive Ifeer Interface for Material Requirements Planning, 
Alrimi V. Nishimnlo, William J. dray, and llnrbnru J. Williams 

HP MRP Action Manager Project Management 



October 1992 

The IIP Nerwork Advisor A Portable Test Tool for Protocol Analysis. 
Edmund G. Moore 

Network Advisor Product Enhancement Philosophy 

Embedding Artificial Intelligence in a LAN Test Instrument, Scull 
(1'xlleu; Rml I nivrrieh, and Stephen Witt 

The I "ser Interface for the HP 4980 Network Advisor Protocol Ana- 
lyzer. Thomas A Dnumas 

Object-Oriented Design and Smalltalk 

The Forth Interpreter 

The Network Advisor Analysis and Real-Time Environment, Sunil 
Bhat 

Network Advisor Protocol Analysis: Decodes. Rona ./. Pvnfer 

Mechanical Design Of the HP 4980 Network Advisor. Kenneth R 
Krebs 

Tlie Microwave Transition Analyzer. A New Instrument Architecture 
for I iimponent and Signal Analysis. David .1 Hallo ami John A. 
Windier 

Frequency Translation as Convolution 

Design Considerations in the Microwave Transition Analyzer. 
Michael DelhleJ'sen and John A. Wendler 

A Visual Engineering F'nvironment for Test Software Development. 
Douglas (' BveUte mid Willimn L. Hunt 

Object -( )riented Programming in a Large System 

Developing an Advanced User interface for HP VEE. William L. 
Hum 

IIP VEE: A Dataflow Architecture, Douglus C. Beethe 

A Performance Monitoring System for Digital Telecommunications 
Networks. Giovanni Nieildu. Fevnando M. Seveo, and Alberto 
Valleri n i 

G-Link: A Chipset for Gigabit-Rate Data Communication, ( 'tin -Sun 
Yen, Richard C. Wnlker. Patrick T. Pelruno. Cheryl Stout. Benny 

w.H. Dai, and WUUam J. Moorland 

Hang- Bang Loop Analysis 
December 1992 

A Large-Formal Thermal Inkjet Drafting Plotter; Rotten a. Burlier. 
Samuel A. Slodder, John F. Meyer, and Victor T. Escobedo 

I lesignJet Plotter I 'ser Interface Design: IxNiniing the Hard Way 
about Human Interaction 

Electronic and Firmware Design or the HP DesignJet Drafting Plotter. 
Alfred Hull Mebane IV, James R. Schniedaki; lue-Shuiiin ( 'hen, 
ami Anne P Kutlonayu 

Pen Alignment in a Two-Pen. I.irge Format. Inkjet Drafting Plotter. 
RObert II. Haselby 

DesignJet Plotter Chassis Design A Concurrent Engineering Chal- 
lenge. 'Timothy A. hmgusl 

DesignJet Plotter End Covers Produced by Coiruection 

DesignJet Plotter Mechanical Architecture Development Process, 
David M. Petersen and Chiiong To 

Improved Drawing Reliability for Drafting Plotters, Robert W. 
Ilea mini in p. Josep Hi rail Ad roher. Joan I'mz. ami Isidre Rosellu 

Average Cser Plot 

Acceptable Quality Level Index 

An Automatic Media Cutler fora Drafting Plotter, Valium 
tiinmmio Aiimfujo. David I'cicz. mid Jose/i Abiiln 

Definitions and Measurement Procedures for Cut Quality Par.uncters 
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Reengineering of a User Interface for a Drafting Plotter. Jordi 
Gonzalez, .laume Ayats Ardite. anil Cartes Cnstetlsague Pique 

A Multiprocessor HP-UX Operating System for HP 9000 Computers. 
Douylas V. Larson and Kyle A. Polyrlironis 

Next-Generation Multiprocessor HP-UX 

Advances in Integrated Circuit Packaging: Demountable TAIi, Farid 
Mn I la 

The EISA Standard for the HP 9000 Series 700 Workstations, Vicente 
V. Camnna and Christopher S. Liu 

EISA Cards for the HP 9000 Series 7(H) Workstations, Da rid S. 
Clark, Andrea C. Lantz, Christopher S. Liu. Thomas E. Parker, 
and Joseph. H. Stein melz 



Hoard-Level Simulation of the Series 700 EISA Cards 

Software for the HP EISA SCSI Card, Bill nomas, Alan C. Herkema. 

Erie. G. Tausheck, and Brian D. Mahaffy 

Update on the SCSI Standard 

Adapting the NCR 53C710 to Minimize Interrupt Impact on 
Performance 

An Archilecture for Migrating to an Open Systems Solution, Michael 
E. Thompson, Gmjsan P. Sill, and Jonathan van den Berg 
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lSJ2DACchip 19/Fcb. 

1TL1 HP-IB controller chip 89/Dec. 

A 

Acceptable quality level index .... 37/Dec. 

Accuracy, cut 47/Dec. 

Accuracy, dynamic, network- 
analyzer 107/ Apr. 

Acquisition architecture, 

oscilloscope 11/Feb. 

Acquisition, peak power analyzer . 85/Apr. 

Acquisition processor IC 9, 12/Feb. 

Acquisition unit. 

Network Advisor 30/OcI. 

Active data rule 88/Oct. 

Address generator Sfi, 87/Dec. 

Address prediction 85, 8S/Dec. 

Address verification 88/Dec. 

Adhesive technology 84/Aug. 

Alert manager 67/Feb. 

Algorithm, edge smoothing, 

effects of 71/June 

Algorithm, effective bits 32/Feb. 

Algorithm, frequency response . . . 29/Feh. 

Algorithm, "fill and flush" 72/Feb. 

Algorithm, "fill and lock" 72/Feb. 

Algorithm, raytracing 76/.Iune 

Algorithms, halftoning 99/Aug. 

Algorithms, network 

data reduction 71/Keb. 

Algorithms, network 

data transmission 72/Feb. 

Algorithms, print 7()/.lune 



Amplifier, sensor 83, 91/Apr. 

Amplitude t« time markers 87/ Apr. 

Analysis and real-time (ART) 

environment 8, 22, 29/Oct. 

Analysis data unit 36/Oct. 

Analysis items 30, 36/Oct. 

Analytic signal 55, 70/Oct. 

Analyzer, microwave 

transition 48. G3/Oct. 

Analyzer, network 101/Apr. 

Analyzer, peak power 81/Apr. 

Appearance-based 

color selection 101/Aug. 

Application portability 61/Dec. 

Architecture, acquisition. 

oscilloscope 11/Feb. 

Architecture development, 

plotter 32/Dee. 

Architecture, multiprocessor 56/Dee. 

Architecture, Network Advisor .... 8/Oct. 

Architecture, neural nets 64/Feb. 

Architecture, parallel image 

generation 76/June 

Archive library 46/June 

ARP (address resolution 

protocol) 24/Oct. 

ART (Analysis and real-time 

environment I 8.22,29/Oct. 

Artificial intelligence. 

Network Advisor 11 /Oct. 

ASICs, plotter 18/Dec. 

Assembly, print cartridge 77/Aug. 

Assembly tooling 30/Dec. 

Assertion checks. HP EISA cards . 95/Dec. 

Audio design, workstation 61/Aug. 

Autostore 7, 17, 45/Feb. 

Average detection 94/Apr. 



Average user plot 36/Dec. 

Averaging, peak power analyzer . . 86/Apr. 

B 

Backplane interface, PC ( ISA) ... 11 1/Apr. 

Backward chaining rules 16/Oct. 

Banding 94/Aug., 9/Dec. 

Bang-bang 

phase-locked loop 104, 108, 110/Oct. 

Baseband circuits, 

peak power analyzer 85, 92/ Apr. 

BASIC:, PC 110/Apr. 

Bayer's dither 99/Aug. 

Behavioral models 94/Dec. 

Benchmarks, VXIbus 46/ Apr. 

Binary quantized 

phase-locked loop 104, 108, 110/Oct. 

Binary rale multiplier 51/Feb. 

Binding libraries 47/June 

Blackboard 16/Oct. 

Blade, rotating and linear 42/Dec. 

Bleed, color 69/Aug. 

Block diagram model 72/Oct. 

Board-level simulation 94/Dec. 

Boot process, multiprocessor 

HP-UX 60/Dec. 

Booting HP-UX, HP EISA cards . . . OaTJec. 

BPS (Busy-system Program 

Synthesizer) 37/Aug. 

Branch scheduling 35/June 

Built-in SCSI 30/Aug.. 98/Dec. 

Bus exerciser 31/Aug. 

Bus gasket 83, S4/Dec. 

Bus master 83, 84/Dec. 

Byte swapping 81,91/Dec. 
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("--. Network Advisor 2!VOi. 

Cable-length compensation 66/Apr 

Cable test tool 67/Feb. 

Cache. 

Series 700 7, 16/June. II 14. I!»/Aug. 

Calibration, automatic 95/Apr. 

Calibration, oscilloscope 24. 54/Feb. 

Canned tests 0. 24/Oct. 

CCITTG.821 89/OcL 

( ELEX dictionar>' 55. 59/June 

Certification process. HP-UX 12/June 

Channel resistance 

compensation 97/Apr. 

Chassis design, plotter 28/Dec. 

Check source, 

peak power analyzer 85/Apr. 

Chipset, gigabit-link 103/Oct. 

Chipset, PCX-S 8, 12/Aug. 

Chroma-based color selection . , . 101/ Aug. 

CFELAB 71/Aug. 

CIMT code 104. 105/OcL 

Class hierarchy 81/Oct. 

Client/server 109. Ill/Dec. 

Clock extraction 108/OcL 

Clocks, workstation 13, 2:1. 59/Aug. 

Cockle 9/Dec. 

Coinjection 31/Dec. 

Color inkjet printers 64/Aug. 

Color science 71/Aug. 

Commentators 9/Ocl. 

Communication, 

inierprocessor 113. 115/Apr. 

Communication prolocols, 

VXIbus 1 1/Apr. 

Compensation rode. 

.software pipelining 44/.liine 

Componeni test 57/Oct. 

Composite spring 71/Dec. 

Compositing chips 80/.lune 

Compression/translation 54/Oct. 

Concurrency control 58/Dec. 

CottCutTenl engineering 28/Dec. 

Conditional inversion 

with master transition 101. ID.VOrt. 

Cone angle 42/Dec. 

Constant folding 35/June 

Contexts 8fl/OcL 

CohtraSI function 70/.lune 

Contrast transfer function 68/.lunc 

( oprocessor, 

floating-point .H/.lune, 9, 15. 5(VAug. 

Coprocessor, measurement .. . 110/Apr. 

Counter, synchronous binary 51/Feb. 

CPU chip 8, l.'l, 42, 56/Aug. 

Curl-set 13/Dec. 



Cut quality . . 
Cutter, media 



. . 46/Dec. 
7. 42/Dec. 



Data flow diagrams 1 13/Dec. 

Data linkage table 47/June 

Data locality 26/June 

Data models 

Data presentation, network 74/Feb. 

Data reduction, network 7l/Feb. 

Data transmission, network 72/Feb. 

Data transport 114/Ocl. 

Database management 96/OcL 

Data (low architecture 84'0ct. 

Dc-to-dr converter 20/ Apr. 

Deadlock avoidance 58/Dec. 

Debugger 23/Dec. 

Decodes 9, 34, 37, 39/Oct. 

Defect diagnosis 27/Feb. 

Defects, user interface 50/Dec. 

Deferred binding 52/June 

Degraded minute 90/Oct. 

Demountable TAB 62/Dec. 

Deniux capability 99/Oct 

Dense matrix relay modules 41/Apr. 

Dependency graph, 

software pipelining 43/June 

Design and code reviews 12/June 

Detection, average versus peak ... 94/Apr. 

Detectors, peak power 81,90/Apr. 

Development 

environment 107/Aug., 22/Dec. 

Development process. 

Ill' MRP Action Manager 109/Aug. 

Device models 86/Ocl. 

Dictionaries, electronic 54/.Iune 

Differential SCSI 97/Dec. 

Digital patterns 62.71/Apr. 

Digital test software 69/Apr. 

Digital tester 59/Apr, 

Digital liming 63. 70/Apr. 

1 >igital-to-an;Uog converter 48/Feb. 

Digitizing oscilloscopes, 100-MHz . . fVFeb; 

Disk array 102/Dec. 

Display rale, oscilloscope 18/Feb. 

DMA state machines 91/Dee. 

Document input 63/June 

Document management 64/Jime 

Dpi size, printer, effects of 71/.hme 

Drafting plotter, inkjet (i/Dec. 

Drafting plotter, pen 35/Dce 

Driver, color printer 93/Aug. 

Dry lime, ink 13/Dec. 

Dye selection 70/Aug. 

Dynamic loader 52/June 



Edge effect, cut 47/Dec. 

Edge enhancement 100/ Aug. 

Edge smoothing effects 71/June 

Effective bits measurement 32/Feb. 

EISA 7S/Dec. 

EISA adapter 79/Dec. 

EISA address ma|) 80/Dec 

E1SA and DMA 89/Dec. 

EISA configuration 99/Dec. 

EISA I/O space 81/Dec. 

EISA pipelining 84/Dec. 

Electrical performance. 

IC package 66/Dec 

Electronic dictionaries 54/June 

EMC design, oscilloscope 39, 41/Feb. 

Emulation, device 11 1/Apr. 

Emulation, workstations 7/June 

Emulator strategy 20/Dec. 

Encoding circuitry 107/Oct. 

End covers, plotter 31/Dec. 

Engagement and driving device . . . 43/Dec. 

Engineering graphics 70/Oct. 

Envelope mode. 

peak power analyzer 86/Apr. 

Error correction, plotter 25, 26/Dec. 

Eirored second 89/Oct, 

Ethernet 6/Oct. 

Event log 67/Feb. 

Exception management 88/Oct. 

Execution flow 87/< >ct. 

Execution unit 14/Aug. 

Expert system 11/Oct. 

Explicit loading 50/Jiine 

Expli<it processor affinity 59/Dec. 

Extended Industry Standard 

Architecture (EISA) 78/Dec. 



False locking 100/Oct. 

Faull finder 9, 1 1/Oct. 

FIFO buffer. HP EISA cards 90/Dec. 

Fillers. DAC output 52/Feb. 

Finnware design, plotter 22/Drc. 

Finnware design. VXIbus 24/Apr. 

Finnware. network analyzer .... 108/Apr. 
Firmware, 

peak power analyzer 95, 98/Apr. 

Firmware, workstation 9/Aug. 

First -level processor 92/Oct. 

FLxtures. network analyzer 109/Apr. 

Floating-point 

coprocessor 8/June, 9. 15. 56/Atig. 

Floatingpoint registers . Hi/June, KVAug. 
FORTH 25/Oct. 
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F< >RTRAN compiler 24/June 

FORTRAN optimizing 

preprocessor 24/June 

Forward chaining rules 16/Ocl. 

Fourier transform, image 

evaluation 69, 75/June 

Frame synchronization 109/Oci. 

Frames. LAN protocol 104A )ci 

Frameworks, Network Advisor ... 23/Oct. 

Frequency compression 52/Oct. 

Frequency files 38/Aug. 

Frequency response, 

detector 82/Apr. 

Frequency response 

measurement 29/Feb. 

Frequency translation 52, 61 /Oct. 

Friction, plotter media 13/Dec. 

Front-panel design. VXIbus 21/Apr. 

FTEST 9, 10/June 

G 

GaAs detectors 90/Apr. 

Gate-level models, 

IIP EISA cards 94/Uec. 

General-purpose 

environment 22, 23. 29/Oct. 

Gigabit-link chipset 103/Oct. 

Graphics, workstal ion 10. 60/Aug. 

Grey balancing 100/Aug. 

H 

Halftoning 99/Aug. 

Hardware models 94/Dec. 

I larmonic errors 82, 94/Apr. 

Heuristic processor affinity 59/Oec, 

Hierarchical data abstract ion 16/Ocl. 

Hierarchical uniform grid 78/June 

H1PPI 114/Oct. 

H P Cooperative Services 105/Aug. 

IIP FISA HP-IB card 89/Dec. 

HP EISA LAN card 85/Dec. 

HP FISA PSI card 92/Dec. 

HP EISA SCSI card 87, 97/Dec. 

HP-NI 57/June 

HP-UX 8.06 (multiprocessor) 56/Dec. 

HyperChannel 113/Apr. 

Hypothetical reference 

connection 89/Oct. 

I 

IC. acquisition processor 9, 12/Feb 

IC. carriage 19/Dec. 

IC, CPU S, 13, 42. 56/Aug. 

IC. DAC. 1SJ2 49/Feb. 

IC floaling-point 

coprocessor 9, 15, 5fi/Aug. 



IC. measurement coprocessor . . II2/Apr. 

IC, memory and system bus 

controller 17. 57/Aug. 

IC, PA 7100 21,41/Aug. 

IC packaging 62/Oec. 

IC, pen interface 19/l)ec. 

IC, processor support 18/Dec. 

IC, wavefonn translator 10, 15/Feb. 

ICs, gigabit-link 103/Oct. 

1CA (interface comiector 

assembly) 8, 52/Apr. 

ICE, Image Compute Engine . . 76, 79/.Iune 
IEEE 488.2 24/Apr. 

D3PC (interenvironment process 
communication) 25, 29/Oct, 

IF corrections 66/Oct. 

Ilhunination models 76/June 

Image Compute Engine 76, 79/June 

Image evaluation 68/Jnne 

Image generation, raytraced, 

parallel 7(V.Iune 

Implicit loading 50/June 

Index shifting 35/June 

Indirect DAC 48/Feb. 

Inference engine 14/Oet. 

Information engineering 1 13/Dec. 

Information retrieval 64/June 

Infonnation technology 1()H/Dcc. 

Initial system loader 101/Dec. 

Initiation interval ll/June 

Ink design, color printer 69/Aug. 

Inkjet color printers 64/Aug. 

Instruction sc heduling 17. 30/.Iune 

Instrument control 76/Ocl. 

lustniment library 35/Apr. 

Interface ilriver. EISA SCSI card . 101/Dec. 
Interproeedural transformations . . 26/.Iune 

Interrupt handling 59. 105/Dec. 

Interspace calls 50/Jtme 

I/O controller chip 29/Aug. 

I/O dependent code (IODC) ... 98, 99/Dec. 

I/O process, HP EISA cards 105/Dec. 

I/O system, workstation ... 10. 26. 62/Aug. 

ISA 78/Dec. 

ISA backplane interface IC 112/Apr. 

ITA (interface test adapter) 8, 52/Apr. 

I_T_L nexus 103/Dec. 

1_T_L_Q nexus 103/Dec. 

K 

Kernel code fi/.lune. 56/Aug. 

Knowledge base 13/Oct. 

L 

LAN analysis 66/Feb. 



LAN monitoring 66/Feh. 

UuiProbe 67/Feb. 

LAN troubleshooting 11/Ocl. 

Latching relays 4 I/Apr. 

Level translation circuit 24/Aug. 

lexicographical infonnation 56/.lune 

Lexicon development 59/June 

Line code, gigabit-link 105/Oct. 

Line sensor 24, 36/Dec. 

Linear function test replacement . . 35/June 

Linguistics, computational 54/.lune 

Link controller 84/Dec. 

Linkage tables, shared libraries . . . 47/Jiuie 

Linker optimizations 19, 22/.Iune 

Linker, shared library 47/June 

Logic synthesis 21 /Dec. 

Logical model 110/Dec. 

Lsop invariants 35/June 

Loop optimization 33/June 

Loop scheduling 39/June 

M 

Mainframes, VXIbus 9/Apr. 

Manifold, prml cartridge 82/Aug. 

Manufacturabilily. IC package .... 67/Dec. 

Manufacturing, PA-RISC 

workstations 49/Aug. 

Manufacturing, print cartridge .... 77/Aug. 

Manufacturing test 75/Apr. 

Mass interconnect. VXIbus 52/Apr. 

Master transition 104, 105/Oct. 

Mastered hurst reads 85/Dec. 

Materials management 103/Aug. 

Matrix topology, relays 42/Apr. 

Measurement system architecture . 7/Apr. 
Mechanical architecture, plotter . . 32/Dec. 
Mechanical design. 

Network Advisor 41/Oet. 

Mechanical design, 

oscilloscope 36/Feb. 

Mechanical design, workstation . . 43/Aug. 

Media cutter 7, 42/Dec. 

Media, drafting plotter 1 I/Dec. 

Media stacker, drafting plotter .... 13/Dec. 

Mediation devices 90/Oct. 

Memory access transformations . . 26/June 

Memory and system bus 

controller 9/June, 17, 57/Aug. 

Message-based interface. VXIbus . 1 1/Apr. 

Metrics, verification 41/Aug. 

Microwave transition 

analyzer 48, 63/Oct. 

Mismatch error 82/Apr. 

Model, optical line sensor 37/Dec. 

Model-view architecture 83, 84/Oct. 
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Modulation transfer function 6S/June 

Monitor characterization 102/Aug. 

Morphology 56/June 

MRP (materials requirements 

planning) 103/Aug. 

MSButfl- 87/Dec 

Multiple application 

management 77/()cl. 

Multiprocessor HP-UX 56/Dec. 

N 

Natural language 

processing 64. 57. 63/June 

Network Advisor tVOct. 

Network analyzer 101/Apr. 

Network elements 90/Oct. 

Network map 67/Feb. 

Network monitoring system 89/OcL 

Network planning tool 75/Feb. 

Neural [lets 62/Fel>. 

Nexus 103/Dec. 

Node aging 71/Feli. 

Node discovery 9/Oct. 

Node traffic chart 67/Feb. 

Noise reduction 53/Oct. 

Nonlinear device measurements . . 4S/( let . 
Nonlinearily, detector 81/Apr. 

0 

Object-oriented design 23, 24/Oct. 

Object-oriented programming . 70/Oet. 

Objects 81/0ct. 

Offline software, HP EISA cards . 97/Dcc. 

Offset voltage compensation !I7/Apr. 

I inline software. HP EISA cards - . 97/Dec. 

Open systems 109/Dcc. 

( iperating system. VXIbus 29/Apr. 

t Mentions systems 90/Oct. 

Optimization, Series 7(X) 17/JlUlC 

Oscilloscopes. 100-MHz 6/Feb, 

P 

PA 7100 chip 21,42/Aug. 

Packaging, IC 62/Dec, 

Packel size display 67/Feb. 

Packet trace tool 67/Feb. 

Parallel raytraced image 

generation 76/Jiine 

Parallelism, cut 46/Dec. 

PA-RISC 1.1 architecture 15/.lune 

PA-RISC extensions 18/Aug. 

PA-RISC multiprocessor 

architecture 5(i/Dec. 

PA RISC simulation 21, M l, :»1/Aug. 

PA-RISC workstations 0, 55/Aug. 



Partitioning, network 76/Feb. 

Pattern halftoning 96. 99/Aug. 

Pattern, test 69/June 

PCX-S chipset 8, 12/Aug 

Peak detect 8/Feb 

Peak detection 94/Apr 

Peak measurements, microwave . 81/Apr. 

Peak power analyzer 81/Apr. 

Pen alignment 24/Dec. 

Pen problems 35/Dec. 

Penetration depth 42/Dec. 

Performance. EISA SCSI card . . . 104/Dec. 
Performance, 

multiprocessor HP-l'X 60/Dec. 

Performance, printhead 74/Atig. 

Perfonnance, Series 7(K) 

workstation . . . 2()/.Iune, 10. 21. 55, 02/Aug. 

Performance. Series 700 

FORTRAN 31/June 

Peripheral device driver 101/Dec. 

Peripheral units 92/Oct. 

Peri'endicularity. cut 46/Dec. 

Persistence, oscilloscope 45/Feb. 

Persistence. 

peak power analyzer 86/Apr. 

Phase-locked loop, binary 108/Oct. 

Phase trigger 56/Oct. 

Photorealistic rendering 76/.lune 

Ping 13/Oct. 

Pipeline. CPU 13. 20/Aug. 

Pipeline scheduling 1 l/.Ium- 

Pipeline stall -lO/.Iune 

plabel 49/June 

Plotter, drafting. inkjet (i/Dec. 

Plotler, drafting, pen 35/Dec. 

Position independent code. 

I IP I X shared library I8/June 

Power environment 65/Dec. 

Preprocessor, FORTRAN 24/June 

Print algorithm effects 70/.Iune 

Print cartridge, color 69/Aug. 

Print engine control 17/Dec. 

Print quality, drafting plot t it 8, 35/Dec. 

Print quality tester 91/Aug. 

Printer characterization 102/Aug. 

Printers, color inkjet 64/Aug. 

ProbeView 67/Feb. 

Procedure linkage table 47/June 

Process development 30/Dee. 

Processing unit. 

Network Advisor 31/Ocl. 

Processor dependenl code 

(PDC) 98/Dec. 

Processor scheduling 6! (/Dec. 

Profile-based procedure 

repositioning 22/.lune 



Project delay 50/Dec 

Project management. 

HP MRP Action Manager 108/Aug. 

PROLOG 11. 16/Oct. 

Protocol anal>-sis 6. 34/OcL 

Protocol analyzer 6. 12/OcL 

Protocol decodes 9. 34/Ocl. 

Protocol follow-ing 7/OcL 

Protocol stack 22, 3a'Oct- 

Protocols. data link 91A)ct, 

Prototyping, rapid 50/Dec. 

Pseudoinstruments 26/Apr. 

Pseudorandom test technology . . . 37/Aug 

Pulsed-RF measurements 48/Oct. 

PuU in 103/Aug. 

Push out 103/Aug. 

Q 

Quad photodiode sensor 24/Dec. 

Quality control plan. Series 700 . . . 12/June 

Quality, telecom circuit 89/Oct. 

QuickView 67/Feb. 

R 

Race avoidance 58/Dec. 

Rasterization 94/Aug. 

Riitioing. peak power analyzer 87/Apr. 

Rayt racing 76/.Iune 

Receiver, network ;utalyzer .... 106/Apr. 

Receiver chip, gigahit-link 104/Oct. 

Reentraney 31/Apr. 

Register allocation l7/,lune 

Register-based interface. VXIbus . 19/Apr. 

Ri'gisler reassociation 33/Jane 

Regression testing 108/Dec. 

Relationship inalrix 42/Dec. 

Reliability, cutter 4.VDec. 

Reliability, drafting plotler 35/Dec. 

Reliability, DTAB 75/Dec. 

Remote links 92/Oct. 

Remote test system, network 89/Oct. 

Rendering, photorealistic 76/June 

Repainting 82/()ct. 

Resolution, effects of printer 71/June 

Resource management 32/Apr. 

Resource reservation table 42/.June 

Reuse, code 22/Dec. 

Rework estimation 51/Dec. 

RF filtering 68/Oct. 

RISC, Network Advisor 8, 22, 29/Oct. 

R1S( ' workstations 6, 55/Aug. 

Risk assessment 50/Dec. 



© Copr. 1949-1998 Hewlett-Packard Co. 



December 1092 Hewlett-Packard Journal 125 



.Safely, prim cartridge 76/Aug. 

Sample rate, oscilloscope lN/Fob. 

Sampler operation 63/Oct. 

Sampling, periodic 50/f 

Sampling, random repetitive 85/Apr. 

Scalability, CPU 20/Aug. 

Scalar iransfoniiations 25/Jiuie 

Scatter halftoning 96/Aug. 

sci-fi iir>/()ct. 

SCPI (Standard Commands 
lor Programmable 

Instruments) 15, 25, 42/Apr. 

Screen update rate, oscilloscope . . 19/Feb. 

SCSI 30/Aug., 87, 97/Dec. 

SCSI-2 103/Dec. 

SCSI LUNs 103/Dec. 

SCSI SCRIPTS 106/Dec. 

SCSI target emulalor 107/Dec. 

Segment map 67/Fel>. 

Semaphore data trap analysis .... 58/Dec. 

Semaphores 57/Dec 

Sensitivity, oscilloscope 82/Apr. 

Sensor, Optical color line 36/Dec. 

Sensor, quad photodiode 24/Dec. 

Sensors, peak power 82, 90/Apr. 

Serviceability, 1C package 67/Dec. 

Shadow registers 7/.lune, l.i/Aug. 

Shared library 46/June 

Sharpness, media cutter 42/l)ec. 

Shear angle 42/Dec. 

Shear joint 82/Aug. 

Shielding, mull ilayer 84/Apr. 

Shingling 97/Aug. 

Signal environment 64/Dec. 

Signal test 57/Oct. 

Signal ! o-noise ratio 34/Feb. 

Simulation, behavioral, ASIC 20/Dec. 

Simulation, functional 21/Uec. 

Slitting device 43/Dec. 

Smalltalk ( Network Advisor) . . 23, 24/ Oct. 
Software, network monitoring .... 95/Oet. 

Software pipelining 39/June 

Softwar e release process 51/Aug, 

Source, network analyzer 105/Apr. 

Sparse-page directory 8/June 

Spatial frequency methods 68/June 

Spatial subdivision 78/.Iune 

Specification, user interface 51/Dec. 

SPEC marks 20, 32/.Iune 

Speech technology 63/June 

Spinlocks 57/Dec. 

Stacker, plotter media 13/Dec. 

Stage count 43/June 



Startup, data link 109/Oct, 

Stationary sampling 58/Oct . 

Statistics, Network Advisor 7/Oct. 

Statistics tool 67/Feb. 

Sliffness, plotter media 13/Dec. 

Stimulus modeling 95/Dec. 

Storage, oscilloscope 7, 45/Fel). 

Straightness, cut 46/Dec. 

Straighlness, line 9/Dec. 

Strength reduction 34/.Iune 

Subviews 82/Oct. 

SurePlot drawing system 35/Dec. 

Symbol binding, shared library . . . 53/.lune 

System bus interface chip 17, 60/Aug. 

System deskew (ifi/Apr. 

System integration, VXIbus 5(VApr. 

System migration Ill/Dec. 

T 

TAB, demountable 62/Dec. 

Tagged queuing 103/Dec. 

Technical architecture 110/Dec. 

Telecommunications network 

monitoring 89/Oct. 

Temperature dependence, 

detector 81/Apr. 

Test cases 50/Dec. 

Test cases, EISA SCSI driver .... 107/Dec. 

Test pattern 69/June 

Test plan, EISA SCSI driver KlfVDee. 

Test program generation 72/OcL 

Test system, oscilloscope. 

built-in 21/Feb. 

Testability 21/Dec. 

Testing, EISA SCSI driver 106/Dec. 

Testing, 

Series 7(K) 13. 14/June. 18, 31, 34/Aug. 

Testing. Series 700 FORTRAN 30/.Iune 

Thermal performance, 

IC package 66/Dec. 

Threads 86, 87/Oct. 

Time window ing 86/Apr. 

Timing analysis 21/Dec. 

TLB 8/June 

TLB design 15/Aug. 

TMN architecture 90/Oct. 

Token ring network 18/Oct. 

Toner, effects of 72/June 

Tooling and molding. 

Network Advisor 45/Oct. 

Transformations, FORTRAN 

compiler 25/,Iune 

Transition analyzer. 

microwave 48, 63/Oct. 

Translation/compression 54/Oct. 



Translation 

lookaside buffer 8/June, 15/Aug. 

Transmitter chip, gigabit-link .... 104/Oct. 

Trends displays 67/Feb. 

Trigger conditioning 86/Apr. 

Triggering, microwave transition 

analyzer 53/Oct. 

Troubleshooting, 

oscilloscopes for 57/Feb. 

u 

Unavailable second DO/Oct. 

Uniprocessor emulation 59/Dec. 

Uniprocessor overhead 60/Dec. 

User interface, IIP VEE 78/Oct. 

User interface, microwave 

transition analyzer 59/Oct. 

User interface, 

Network Advisor 8. 22/Oct. 

User interface, plotter 12, 49/Dec. 

User objects 82, 86/Qct 

User panels 81/Oct. 

V 

Vector library 29/June 

Vector modeling 94/Dec. 

Vector-to-taster converter 16/Dec. 

Vector transformations 2G/June 

Verification vs. 

characterization 21,22/Fcb. 

Verification, VLSI 34/Aug. 

Version control, 

HP-UX shared library 53/.Iune 

Vertical calibration 98/Apr. 

Video response 82/Apr. 

Views 81, 84/Oct. 

Virtual instruments 26/Apr. 

Virtual memory, PA-RISC 49/June 

Virtual ribbon cable 103, 113/Oct. 

Visual engineering environment . . . 72/Oct. 

Vision, machine 87/Aug. 

VLSI packaging 62/Dec. 

VLSI, workstation 8, 12. 18/Aug. 

VMEbus 6/Apr. 

Voxels 78/June 

VX1-OS 29/Apr. 

W 

Waveform translator IC 10, 15/Feb. 

Waviness. cut 46/Dec. 

Word classes 58/June 

Word-serial protocol 12/Apr. 

Workstations 6. 55/Aug. 
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HP 49S0A I IEEE 802-3 and IEEE 802.5) Network Advisor Oct 

IU' 4981A (IEEE 802.3) Network Advisor Oct 

HP 4982A i IEEE 8025) Network Advisor Oct. 

HP 4990A Probe View network monitoring software Felt. 

HP 4990S LanProbe distributed LAN analysis system Feb. 

HP4992A node locator Apr. 

HP 8751A network analyzer Apr. 

HP 3990A peak power analyzer Feb. 

HP 9000 Series 700 FORTRAN optimizing preprocessor June 

IIP 9000 Series 700 workstations Aug. 

HP 25525A EISA SCSI-ll host adapter Dec. 

HP 25660A EISA HP-IB host adapter Dec. 

HP 25567A EISA LAN/9000 host adapter Dec. 

HP MRP Action Manager Aug. 

HP41802A 1-MQ input adapter Apr. 

HP 54H00A oscilloscope Feb. 

HP 54601A oscilloscope Feb. 

HP 54655A/56A test automation module Feb. 

HP 54657A/58A measurement/storage module Feb. 

IIP 70OO4A MMS mainframe Oct 

HP 70820A microwave transition analyzer module Oct. 

HP 71500A microwave transition analyzer Oct. 

HP 75000 Model D20 digital functional tester Apr. 

IIP 75000 VXIbus instruments Apr. 

IIP 82324A measurement coprocessor Apr. 

HP M4812A, 84813A, 848I4A peak power sensors Apr. 

IIP 8751 1A s-paramt'ler test set Apr. 



HP 87512A transmission/reflection test set Apr 

HP DesignJet large-format inkjet drafting plotter Dec. 

HP DeskJet IMG printer Aug 

HP Desk Writer G printer Aug 

HP DraftMaster Plus large-format drafting plotter Dec. 

HP El 300 Series B mainframe Apr. 

HP E1400 VXIbus mainframe Apr 

HP E1405 VXlbUS command module Apr 

HP E141UA RF power meter Apr. 

HP E 1 426 A digi 1 1 zing oscilloscope Apr. 

HP E1440A synthesized function/sweep generator Apr. 

HP E1465A dense matrix relay module Apr. 

HP E1466A dense matrix relay module Apr. 

HP E14G7A dense matrix relay module Apr. 

HP E1496A digital test development software Apr. 

HP E35H0 digital performance monitoring 

and remote test system Oct. 

HP E3720A VXIbus interface connector assembly Apr. 

HP E3722A hinged interface connector assembly Apr. 

HP E3730A interface terminal module terminal board Apr. 

IIP HDMP-1000 gigabit link chipset Oct. 

HP J2159A EISA X.25/9000 Series 700 Dec. 

HP LanProbe network monitor Feb. 

HP ProbeView network monitoring software Feb. 

HP ScopeLink oscilloscope-to-PC software Feb. 

HP-L"X 8.0(5 multiprocessor operating system Dec. 
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